author : Eric Evans

We're often exhorted to do "domain-driven design" -- to build (computational) models of the (business) domain, and implement those models as the relevant business software system -- but how do you actually do this, and does it work? Here Evans provides a Pattern Language, commentary, and interesting examples, to provide a guidebook for the doings, and anecdotes about his extensive experience in the industry, to provide evidence that it does indeed work.

I found the argument compelling. There are patterns to help the initial building of the domain model through a process of deep knowledge crunching, building a UBIQUITOUS LANGUAGE, for structuring the system with a LAYERED ARCHITECTURE and with SERVICES, for keeping identities clear by distinguishing ENTITIES from VALUE OBJECTS, and for continually refactoring it within an agile development process to produce a supple design that includes INTENTION-REVEALING INTERFACES, CONCEPTUAL CONTOURS, and DECLARATIVE DESIGN. This is accompanied by other patterns covering doing this for real -- in a large project, with legacy code, with other teams doing it differently, and so on. This is where the book differs from other more idealised accounts: the real world is messy, but DDD is valuable, so here's how to do it the best you can in less than ideal circumstances, including using a BOUNDED CONTEXT, maybe defining a SHARED KERNEL, building ANTICORRUPTION LAYERs, and keeping the strategy visible through a SYSTEM METAPHOR.

The examples are also good. They are based on real projects Evans has been associated with, and are more complex, and more interesting, than the usual toy examples. They give a great insight into the deep knowledge crunching he advocates. In particular, the core classes are not the obvious "nouns" in the system, and discovering them requires deep (business) domain knowledge -- for example, his cargo shipping system has no "ship" or "container" classes. This deep knowledge requires developers to talk to the domain experts.

I tried some of the ideas in here on my most recent (very small!) development. This was a re-engineering of an already existing system, so I already had what I felt to be an adequate model. But following the patterns and methods here, I uncovered a new domain concept that substantially clarified that model. I'm sold!