Domain Driven Design by Eric Evans

Tackling Complexity in the Heart of Software
Eric Evans, Prentice Hall Ptr 2004, ISBN 0321125215

Eric Evans discusses the benefits of having a good domain model at the heart of a software development effort and what that means for an agile team.

This book comes as a bit of a surprise to those who have been taught that agile software development and especially eXtreme Programming do away with the need for analysis and design techniques like object modeling and notations like the Unified Modeling Language (UML).

For example, the book has a foreword by Martin Fowler, one of the authors of the popular book, Planning Extreme Programming(amazon.com ,amazon.co.uk), and a recommendation on the back cover by his co-author Kent Beck, who is also the author of the original text on eXtreme Programming, eXtreme Programming Explained (amazon.com, amazon.co.uk). How can this be?

However, after a moments consideration, the surprise should disappear into a blaze of renewed enlightenment. It is actually very obvious that any software team working in a .Net language, Java, Objective-C, C++ or any of the object-oriented dynamic languages such as Python or Ruby has an object model at the heart of their software. This model is formed by the business or domain objects that they have defined, the references between them and the ways objects of these classes collaborate with each other to deliver the desired function of the software system or component.

Unfortunately, in many so-called agile teams, this model remains buried inside a plethora of source code text and is largely invisible to the domain experts, product managers and business-oriented folk on the project. Even worse, the model may be intricately woven through technology-oriented code files dealing with user-interface, persistence and interfacing with external systems. Parts of the model may be unnecessarily duplicated, be inconsistent with other parts, and the whole thing poorly match the actual business ideas it is trying to represent. At best, developers produce some fleeting partial sketches on white-boards. The result can be high amounts of rework, mis-labeled as refactoring, as developers rush to code the first conceivable solution that might work for a particular feature (user story, backlog item, agile use case, etc), but then struggle to extend the code to support the next user story.

One of the reasons that agile development teams mistrust anything to do with object modeling, is the enormous wastes of time and resources at the end of the previous century spent in formal object modeling efforts. These object modeling efforts typically required large upfront analysis and design activities that produced beautifully-diagrammed, highly detailed models described in sets of documents or expensive, unwieldy modeling tools. However, beautiful formatting does not make up for poor content. Despite, and frequently because, of the level of detail in the models,  they were often incomplete, inconsistent, incorrect and, because the modeling effort nearly always overran its schedule, still changing. Given this and the fact that the models were produced by analysts and designers and then thrown over the wall to developers that took no part in the modeling process and had inadequate training in the nuances of the notation used in the diagrams, the model of classes, references and collaborations in the source code very rapidly diverged from that in the documents. This very soon rendered the models in the documents and expensive tools worse than useless. And simply pinning a large printout of the model on a wall does not solve the problem here as illustrated by an experience described by the author at the start of chapter 3.

Domain-Driven Design claims the key to success is to 'bind the model and the implementation'. In other words, the model as shown in diagrams prominently pinned to development team meeting-room walls shows a model that is intimately linked to the model of classes, references and collaborations in the source code.

One obvious way to do this, is to involve developers in the process of building the model. In chapter 1 of the book, Eric describes an initial brainstorming modeling session he had with a domain expert. This resulted in a useful model but far more valuable, Eric as the developer gained knowledge and insight into the domain during the process of building the model. Eric calls this collaborative brainstorming model-building activity, knowledge crunching. Incidentally, in many cases, the domain experts participating in such sessions come to a deeper and better organised appreciation of the domain too.

This initial, collaborative, brainstorming, model-building activity reminds me very strongly of process one defined in Feature-Driven Development (www.amazon.com, www.amazon.co.uk), Jeff De Luca's , highly-iterative, model-centric development process.

In addition to the knowledge gained during the modeling sessions, the terms used to name items in the model start to form an unambiguous vocabulary shared by both the domain experts and the developers involved. This shared vocabulary is soften so valuable that Domain-Driven Design gives it a name, calling it the ubiquitous language of the project. The idea that the terms in the model become a vocabulary shared between domain-experts and developers is not a new one but its importance tends to be underestimated. Whether you like the name or not, naming the shared vocabulary immediately raises its profile in a similar way that giving a name to a design pattern does. Most younger developers can converse in terms of strategy patterns, factory patterns, etc., from the names given to design patterns by the gang of four in the 1990's. Giving a name to this shared vocabulary does something similar for this important result of collaborative, brainstorming object modeling activities.

The first half of the Domain-Driven Design book continues in a similar vein. It has little that is actually new but does what all good books of this type do, and that is clearly define and give a name to commonly used patterns, useful strategies and proven best practices. There is not much to complain about here and someone new to modeling will find the descriptions of different kinds of building block class useful. However, it certainly is not groundbreaking in the quite the same way that Peter Coad's class archetypes, or Nicola, Mayfield and Abney's 12 collaboration patterns described in their book, Streamlined Object Modeling are.

From chapter 10 onwards, things change. The book starts to introduce much more sophisticated ideas, patterns, and strategies. Here is more than enough food for thought, even for the most experienced object modeler or agile designer/developer.

Personally, I find the ideas in the book complement those in Java Modeling In Color and they fit very well into my understanding of the use of modeling within FDD as described in A Practical Guide to Feature-Driven Development. The book is also another reminder that agile development is not an excuse to skimp on analysis or design and dive into coding undocumented, unmaintainable software. It it actually the complete opposite. True agile development requires more discipline and professional maturity than older approaches because there is no heavy-weight, high-ceremony process to hide behind.

Recommended reading!

One final note on the name: I believe all software development efforts must ultimately be requirement-driven. After all, it is the project's responsibility to deliver software that functions as the paying client requires. Therefore, I dislike terms such as model-driven development. The model does not drive development; the requirements, whether you call them features, backlog items, user stories, functional requirements or use cases, should drive development. Development should be centred around the model, not driven by it. Thankfully, this is domain driven design and not domain driven development. This makes a bit more sense in that the design of the functions needed to meet a requirement is driven by the domain while the overall development effort is driven by the requirements.