Facets and Domain-Driven Design

The thrust of this book is that one model should underlie implementation, design, and team communication. Having separate models for these separate purposes poses a hazard. (Evans, 2004, 41)ⁱ

Eric Evans' statement describing his book, Domain-Driven Design, is loaded with implications to waterfall software development that might not be apparent on first glance. Eric does a good job of discussing these implications sporadically through the book, but a few of my favorite are worth noting here:

[Waterfall] fails because it completely lacks feedback. .. Knowledge trickles in one direction, but does not accumulate. (Evans, 14)

The trouble comes when people feel compelled to convey the whole model or design through UML. A lot of object model diagrams are too complete and, simultaneously, leave too much out. (Evans, 35)

The pure analysis model even falls short of its primary goal of understanding the domain, because crucial discoveries always emerge during the design/implementation effort. (Evans, 48)

Model-driven design discards the dichotomy of analysis model and design to search out a single model that serves both purposes. (Evans, 49)

Development becomes an iterative process of refining the model, the design, and the code as a single activity. (Evans, 50)

As demonstrated in Domain-Driven Design, it is impossible to discuss domain-modeling in isolation. When one uses domain-centered architectures it is necessary to account for the deep information-exchange between the business and IT, thereby explaining the difficulty of speaking to domain-driven design without also addressing its broader implications. For much the same reason, it is very difficult to understand the value of GemStone Facets, or GemStone-S, without first having an understanding and appreciation for the value of domain-models.

One of the most striking traits that I have found of software development practitioners with an affinity for GemStone System products is their passion for their craft manifest in a deep understanding of the full life cycle of software development. I believe the reason for this is the recognition that GemStone's smalltalk and Java object database products make easy one of the most difficult aspects of building software for business: understanding, implementing and refactoring the domain-model, which is a full life cycle endeavor. In fact, like domain-driven design, this product suite is predicated on the existence of a domain model in an isolated layer of the architecture.

With Eric's book as context, the following two articles attempt to explain: 1) why Facets is compelling when domain-models are employed, and 2) how Facets in particular relates to the concepts of Entities, Aggregates and Repositories within domain-driven design.