Domain-Driven Design: Tackling Complexity in the Heart of Software

There are many software engineering processes out there, and each one tries to tackle the complexities of designing software applications for a given domain in its own way. Evans recognizes the tools and the processes that are popular in the industry, UML, Agile, and focuses on some aspects of the software engineering process that we tend to miss. He starts the book by talking about the importance of creating and having a Ubiquitous Language. There is a similar concept in the RUP, but not emphasizes as much - or at all. Evans goes into a great detail on why, from the inception of a project, it is important to have a common language and gives many pointers on what makes up the Ubiquitous Language for each project:

"Use the model as the backbone of a language. Commit the team to exercising that language relentlessly within the team and the in the code. Use the same language in diagrams, writing, and especially speech."

Parts II-IV of the book put domain-driven design in perspective, and show the reader thru examples and patterns, architectural patterns, design patterns and process patterns, the importance of having a consistent model that maps to the domain and how to go about achieving such model. In an essence, "Model-Driven Design discards the dichotomy of analysis model and design to search out a single model that serves both purposes".

Part II of the book, introduces the building blocks of a Model-Driven Design. This section, as with the others, takes popular patterns from the Gamma, Flower, or others and applies them to the topic at hand - Model-Driven Design. In that aspect, the reader can easily follow the text and relate to topic at hand. Evans uses the ever-popular Model-View-Controller (MVC) design pattern to get things going in part II. He then goes off to explain why the layered architecture approach is an important aspect of a Domain-Driven Design and how it would makes things simpler:

"[Layered Architecture] allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work."

The author then goes into great detail in explaining the elements that express a model:
1) Entities: An object that is tracked thru different states or even across different implementations.
2) Value Objects: An attribute that describes the state of something else.
3) Services: Aspects of domain that are expressed as actions or operations, rather than objects.
4) Packages: Organize the objects and services.

What do you want to do after you have designed such elements? The creation and life cycle management of objects are discussed next in this book. Three patterns, mostly from the Gamma book, are used to manage the life cycle of objects:
1) Aggregates.
2) Factories.
3) Repositories.

Aggregates represent the hierarchy of objects or services and their interactions. Factories and Repositories operate of Aggregates and encapsulate the complexity of specific life cycle transitions.

Part III of the book talks about the things developers and architects need to do to achieve a Supple Design. Refactoring over and over represents the topic in this section:

"Each refinement of code and model gives developers a clearer view"

The author talks about a breakthrough point during the design that the "designers see the light" and both the domain experts and the designers, after many iterations, have finally come to this higher level of understanding of the domain and the value of refactoring exponentially increases after that.

Part IV of this book talks about a very important topic that we all have struggled with one time or another: the ability of the model and the modeling process to scale up to very complicated domains. It is great that we can model a small domain, but one goes about modeling an enterprise, which is most likely, too complex to model as a single unit? Low-coupling and high cohesion still applies here, but the goal is to not loose anything during the integration process. The author goes in to a great detail in this part to emphasize that even in large circumstances such as modeling an enterprise, every decision must have a direct impact on system development. Three different themes are covered in this section in order to assist with modeling of large units:
1) Context: the model has to be logically consistent throughout, without contradictory or overlapping definitions. For this theme, the author introduces the concept of a Bonded Context- a way that relationship to other context are defined a overlapping is then avoided.
2) Distillation: Reducing the clutter and focusing attention appropriately.
3) Large-scale Structure. The concept of Responsibility layers are introduced

In summary, Evans did a great job in writing this book, and filling it with useful ways of designing and architecting software applications that target a domain, which in most cases we do not know much about.


Read this book to graduate from programmer to designer   September 25, 2003
Brad Appleton (Arlington Heights, IL USA)
44 out of 50 found this review helpful

I think that this book along with Robert Martin's "Agile Software Development, Principles, Patterns, and Practices" and Martin Fowler's "Refactoring" are perhaps the three most fundamental prerequisites for making the leap in knowledge and maturity from object-oriented programming to true proficiency in object-oriented design. The books from Martin and Fowler cover the software solution design space and the core principles and patterns for making code that is resilient to change and easy to maintain. Eric Evans book covers the problem domain space and the abstraction skills that free programmers to "break out of the box" of the implementation domain and solution objects into the critical area the business domain and corresponding domain objects.

I once led a young software team and tried to convey the need for and essence of these skills to them, but I didnt have the right words and terms to do it for their level of experience. I wish this book had been available to me then because I think it would have made a real difference for that team.


Domain-Driven Design   March 1, 2006
Janek Claus
12 out of 13 found this review helpful

This book is fantastic, a great resource and an excellent reference. To abstract and distill a business domain goes beyond implementing every single requirement, it goes deeper and yields better results for the organization, Eric Evans captures this hard-to-teach process and lays it out in clear text. In short, I highly recommend it for any developer, technical lead or architect's book shelf.

A lot has been written about technical frameworks, patterns and implementations, but none tackled this complex topic in such detail before. This book is very dense and written with great care, insight and logical structure. Sometimes, I felt like the author can read my mind: I was reading a chapter and thought: "Fine, this looks good in theory, but what's a good way to apply it?", and promptly the text was folled by an example. In a lot of cases those are not fabricated, but taken from his extensive experience. One can see why it took the author over 4 years to write the manuscript.

I am not only writing from reading the book, as a principal engineer and architect I actually applied the knowledge I solified and gained through the book to a medium-sized project. My expectations were rather modest given my inexperience with domain modelling. However, the project was hugely successful. I attribute that to the very logical layout of the book. I had no problem organizing and memorizing the vast knowledge of 500 dense pages, so it can be applied successfully. I suggested that all of my developers are going to read the book, so we can have a UBIQUITOUS LANGUAGE about the domain of domain modelling.

I was especially pleased with the testability of the domain model. We started programming the model very early in the modelling phase, but because no frameworks or libraries were involved, it was easy to test. In addition we developed scenarios to prove the validity of the model (and how it can meet certain business requirements) and attain feedback from the domain experts.

The only negative point I have to make about this approach is that it requires the willingness of the clients or users to think about their business processes and have the intelligence to explain them. I know this seems silly, but I have dealt with users that want a system to automate their processes, but then refuse or are relunctant to talk or think about it. Most of them I could convince of the value and after a few weeks they finally realized: wow, this is really cool, I actually understand, what those folks are doing, I am involved and they seem to understand me, too. I would call that a break-through.

To sum up, software development with my guidance was always going in that direction, but I never managed to write it down nor explain exactly what I was doing. Eric Evans has a very clear style of explaining this rather fuzzy area of domain exploration, distillation and modelling. It helped me a lot.


Solid Reminder to work with the SME   September 2, 2005
Scott Brookhart (Austin, TX USA)
8 out of 8 found this review helpful

As a developer it is quite easy to take the requirements, do some design and go off and code and come back with a product only to find out later, that the customer really did not want the developer's interpretation of the requirements. This book is more than a reminder of this notion, but also lays out some examples of real experiences of deriving the model. Software engineering is one of those areas that require the trade of knowing the technical development skills and also acquiring great understanding of the domain to be abstracted, developed and made into something computerwise tangent. This is a great book for developers, business analysts, project managers, and anyone in the software business. While others may not regard this book as one of the classics, I find this book an important reminder lest we forget why we are developing the software and the perspective to take while working with the customer.
Thank you, Eric for such a work.





A Framework for Proper Object Thinking   May 16, 2004
Christopher Gardner
5 out of 6 found this review helpful

This book may change the way you think about software design. Of all the software books I purchased over the last year, this book ranks as one of the most important (another is Lean Software Development by Mary and Tom Poppendieck). The book presents an elegant pattern language to help the modeler understand and design the domain in which he is crafting software. The pattern language addresses both the human factor of modeling (i.e., effective communication with all stakeholders) and the technique of modeling (i.e., the application of object concepts).

This well-organized book succeeds on many levels:

* It helps prepare the modeler to work with his domain by suggesting he must develop the right mindset and communicate with the people who understand the domain.

* Emphasizing the need to keep the domain model as pure as possible, it explains the absolute fundamentals of a domain model, including the all-important notions of entities, value objects, services, and modules. It presents the object-lifecycle, including the mechanisms of factory and repository (and their advantages).

* It provides techniques for object discovery and refinement and model flexibility.

* It provides ideas for organizing cooperative teams.

* It is highly compatible with agile processes, such as eXtreme Programming (XP). In fact, the author himself has practiced XP.

This book should be the second book a novice modeler should purchase. A seasoned modeler should buy this book immediately.