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

Eric Evans (2003)
Review date: September, 2008

The book is comprised of four rather distinctive parts. In the first part, the most central and important aspects are introduced: the ubiquitous language and the importance of having correct models that reflect the organization's business. These concepts, along with some explanation and argumentation are forged into the term domain design.

The second part is what one could call most "mechanical". It discusses the author's way of implementing software designs using entities like factories, aggregates, services, repositories, entity and value objects, and the concept of layered architecture. These things are explained in depth with numerous examples and surrounding discussions.

"Refactoring toward deeper insight" is the name of the next section, where a lot of ground is covered. First comes a story about spectacular breakthroughs that take the design to a different level via refactoring. Then we learn how to make implicit concepts more tangible. "Specification", the author's only true design pattern is discussed in length. Supple design, another central and powerful concept in this book is decomposed to, and described by concepts such as assertions, side-effect-free functions, intention-revealing interfaces, and closure of operations, to name the important ones. Declarative development is highly promoted as more explicit, and a generally desirable outcome. At the end of the section, there's a slight switch of focus, where the author discusses appliance of Martin Fowler's analysis patterns and some classic design patterns.

Strategic design is the closing topic. Here the author introduces various strategies for managing larger designs, the implementation of which spans over multiple teams. The central concept here is the bounded context, that defines a piece of the system with a clear or natural bound, and that can live in isolation, at least from developers' point of view. Apart from that, solutions such as shared kernels customer/supplier development teams, anti-corruption layers, and distillation, the process of extracting the essence of the knowledge expressed by the model are developed in depth.


This is a big book. Differently phrased: it contains a lot of information on a lot of different topics. Writing a just summary was difficult, and I can promise you that my version doesn't even convey half of the concepts described in the book, and still it contains some heavy simplifications.

Logically, the information density makes this book a poor candidate for speed reading. New topics and concepts appear constantly, and it's difficult to skim through portions of it without reading them properly. I can definitely say that I will reread this book in a couple of years when I've acquired greater experience in large designs. Some concepts are simply too difficult for me to discuss professionally, but more on that later.

The easiest thing to do is probably to judge this book part by part.

In the first part the author describes the need of an ubiquitous language and the importance of the model being able to reflect the business core domain. This is a part that's easy to read and agree with. The author sells his concept well, and makes a solid case.

In the second part, which really resembles a classical software design book, I felt rather at home. What I liked the most was the author's strictness of how to use the different building blocks (factories, services, repositories, etc). No fuzziness here. Everything is well defined, explained and rests on a solid foundation. This is actually a recurring trait of the author, on which I will elaborate in an upcoming section.

Third part: this is where it gets a bit straggling. Here starts a mixture of quite hands-on kind of advices and more abstract reasoning. The part consisting of different techniques that may lead the design towards a declarative style is good. However, they are mixed up with discussions, the content and relevance of which isn't always crystal clear.

About the fourth part I don't know what to say. I perceived it as really hard reading and had difficulties to relate its contents to my practical experience. In this mode, I could only nod and say that what I read seemed reasonable, but at the same time it felt a little like a space filler....

Now for the good part, the general impression! Let's start with the downsides.

If this book were a program, I'd say its design suffers from mixing different levels of abstraction! While the bulk of the text works with a certain, let's call it level of abstraction, there occur some drill-downs that are not always motivated. Like the author trying to say: "Look! I know about that too!". I understand the ambition of wanting to include a lot of information, but some relevance sorting would not hurt in some cases.

A close cousin to this problem are the different styles used: dry theory, code snippets, UML diagrams, excerpts of dialogs, hand-drawn pictures, pattern descriptions, and so on. While all these elements do occur in our kind of books, in this one they interact in a way that makes the book look cluttered, hard to read, and in some cases clarity suffers and additional complication introduced because of this mix. Some sections simply contain too much of everything, which is probably one of the reasons for this book not easy to read.

While I'm dissing... The examples get boring. They represent actual problems the author has encountered, and they are realistic enough, but they just keep coming back, chapter after chapter... Keep coming back...

Last but not least, and this makes me really sorry, this author too has suffered from a "claim of fame - I can create new patterns syndrome". Everything in this book is a pattern, which also results on an annoying capitalization of every second word in the text. Not only are the presented advice, techniques, or suggestions not patterns by definition (they are not recurring solutions to common problems, just one person's ideas of solutions), they also make the reading harder.

That was a lot of negative feelings, but don't worry, there a good things to be said too!

We can blame the author for trying to create a million of new patterns, but nevertheless he does make a tremendous contribution to the language of software design by describing and defining many concepts in a clean and clear way. The author manages to name many important things that keep coming back in software design. So, this book offers a great theoretical contribution to the field.

What also impresses me is the author's ambition to define his creations in an almost mathematical way, explicitly striving for zero ambiguity and clean definitions. This, combined with some mathematical reasoning and references to paradigms such as logic programing (finally somebody writes about Prolog!) makes the author an intelligent and structured person. This is a good thing, since many books are written by people who just want to make money by describing what they are doing, without giving it a theoretical basis.

In sort of the same category falls the usage of mind maps, which is yet another of the author's tools. Bigger chapters start with a graphical mind map, that explains how the discussed concepts fit togehter.

A lot of text so far! Read or not read? Read! This book will challenge you. It contains vast amounts of information and gives you a whole new arsenal of tools for attacking modeling and design issues. Reading it will be a long ride though.

Who should read this book

The term "domain-driven design" is mentioned and abused from time to time. People who want to get it right are a natural target audience. This book also offers good advice on how to build a system that is well aligned with the business, and offers great aid especially for new projects.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.