Book Review: Implementing Domain-Driven Design

At the end of 2011 I was privileged to be a technical editor for Vaughn’s Effective Aggregate Design series. Around the same time I also enjoyed hearing Vaughn present a series on effective aggregate design locally at our DDD Denver meetup. So, for the sake of full disclosure, I have known Vaughn personally for years and collaborate often with him on the meetup. I’ve tried to be as impartial as possible in reviewing the book, basing my observations and opinions on the content alone.

I have been recommending Implementing Domain-Driven Design to my students mainly on the basis of the high quality of the aggregate design articles and presentations, and Vaughn’s many significant contributions to the DDD mailing list over the years. But now I am pleased to base my recommendation also on a full read of the Safari Books Online rough cut edition of Implementing DDD.

While there is plenty out there in the way of DDD Resources, what Vaughn has done with this book is to distill much of the wisdom of the DDD community into a single book that provides pragmatic, expert guidance on how best to succeed with implementing DDD. This is the book I want DDD students purchasing and reading alongside the Blue Book.

I thoroughly appreciated the pretension-free way Implementing Domain-Driven Design approaches everything. For example, it introduces domain-driven design (DDD) by stating:

Vaughn’s book comes across as guidance from a good friend, combining occasional corny cowboy jokes that keep it fun with detailed, solid advice on the deepest recesses of the mechanics of applying DDD using the tools and techniques of today.

The book’s approach of developing an application to support Scrum and walking through how the team approached the problems they were up against is very helpful, especially when Vaughn digs into the team’s mis-steps as they learn, adjust and improve. Contrary to any material online which might lead you to think that DDD is about overblown architectures, heavyweight frameworks and obfuscated approaches, in chapter one Implementing Domain-Driven Design counsels that:

There is a very helpful chart that helps the reader identify whether DDD is the right approach in a particular situation. So much of what I read about DDD online seems to be applying it where it will add little value. So much emphasis on how to apply the DDD building block patterns where they are not needed. Sigh.

Some confuse DDD with Big Design Up Front (BDUF), and thus struggle with understanding how DDD and agile relate. I was also pleased that Implementing Domain-Driven Design starts out by emphasizing the agile, iterative, continuous modeling with domain experts that is at the heart of DDD “done well.” For example:

The first chapter also does a good job of introducing the fundamental concepts of Ubiquitous Language, Bounded Context, and Core Domain. It also lays out clearly the costs and benefits of applying DDD, and how DDD as a lightweight, intentional approach to continous design is a natural fit for agile teams. For example:

In chapter two, Implementing Domain-Driven Design covers strategic design. Vaughn’s explanation and application of the distinction between problem and solution space in this chapter is particularly helpful, and I intend to incorporate this approach into how I do strategic design from now on.

This helpful problem/solution distinction at the strategic design level reminds me somewhat of the distinction at the tactical level between the Scenario and Model and Code Probe steps in the Model Exploration Whirlpool. In the Whirlpool the Scenario step is focused on learning and understanding the problem space, and the Model and Code Probe steps primarily address exploring and defining potential solutions. However, the entire process - every step in the whirlpool - is geared towards delving into a deeper understanding of the domain.

Putting strategic design right at the start of the book highlights the relative importance of getting the strategic aspects right: explaining why strategic design is important, and setting the stage for the reader to understand and explore careful application of the building block patterns.

I’ve encountered people who have (mistakedly) confused DDD with efforts to model the overall enterprise, so I heartily agreed with Implementing Domain-Driven Design's advice to avoid the temptation to create a single, enterprise model:

This section also does a praiseworthy job of explaining Bounded Context as intrinsically a linguistic concept: one tied to ubiquitous language and then supported by the technical implementation.

I also appreciated the book’s emphasis on the primacy of focusing attention on the Core Domain, that:

However, in achieving this level of focus on the Core Domain, there is the possibility that teams may neglect Supporting and Generic subdomains, so Implementing Domain-Driven Design's advice in this respect is also timely:

Implementing Domain-Driven Design asks the reader to apply learning to her own domain, by sketching out Bounded Contexts, identifying her own Core Domain and so on in her own team’s situation. Nothing beats practice when it comes to developing new skills.

In the process of applying that new learning, the team is to:

Also, in my coaching I give similar advice to the following when a team tends to get “down in the weeds”:

It is regrettable that over the years DDD has somehow become more associated with overblown architectural approaches than with the strategic, lightweight collaborative modeling Eric Evans has always advocated. I’ve even seen people rejecting heavy-handed architectural approaches and calling them DDD, when what they are rejecting is not DDD at all but rather the burden of carrying extraneous infrastructure and layer plumbing.

Chapter four of Implementing Domain-Driven Design is targeted around architecture, and into our current climate of heavyweight, overblown and overengineered system architectural approaches, this chapter’s risk-driven and pragmatic approach to architecture blows a fresh breath of air:

The architectural chapter is comprehensive and dense, but very good.

I found the best description of ports and adaptors approach that I have read. There is also a good description of CQRS, combined with practical guidance on when and where to apply it as an architectural organizing approach, and how it relates to event sourcing.

Each of the next chapters covers one of the "building block" patterns of DDD in depth: entities, value objects, domain events, aggregates, factories and repositories. In each chapter Implementing Domain-Driven Design explains what the pattern is, when to use it, and various ways to apply it. The book is careful to cover the relative merits and downsides of each approach, and gives technical implementations that show - by example - how to adopt them.

In particular, Implementing Domain-Driven Design's distinction between collection-oriented and persistence-oriented repositories was very helpful, and the examples with how to apply these styles for a variety of common persistence stores, including MongoDB and Coherence.

In the application chapter I would have liked to see more code samples for UI approaches, but I realize that this wish is unrealistic: presentation layer design is a massive topic on its own.

There is an overwhelming and ever-changing diversity of frameworks, UI tooling and associated techniques, and there is only so much that can be included in such a book as this. Implementing Domain-Driven Design wisely lays out the various options and tradeoffs, guiding the reader towards making informed and judicious choices.

Appendix A is an in-depth treatment of event sourcing, contributed by Rinat Abdullin. When I started the book I wasn’t sure about why the appendix was there (asking myself, "isn’t this material covered already in the main text?"), but it actually proved most helpful in understanding the mechanics, advantages and pitfalls of event sourcing.

The event sourcing material here is a superb complement to the rest of the material, building on it in all the most important ways. This A+ES event sourcing chapter is the clearest and best description I’ve found on how event sourcing works. The coding examples provide expert cutting-edge guidance and tooling for getting an event store-based approach up and running quickly.

I have to say it, if it’s not already obvious: I’m a fan. Implementing Domain-Driven Design does a remarkable thing: it takes a sophisticated and substantial topic area in DDD and presentes it clearly, with nuance, fun and finesse.

This book is written in an engaging and friendly style, like a trusted advisor giving you expert counsel on how to accomplish what is most important.

As I read, I found myself highlighting many sections, and will be getting a copy of Implementing DDD for my bookshelf as soon as it is released. I will be referring back to it, and recommending it, often.