Review: Implementing Domain-Driven Design

Given the size of the fields and its multiple levels of application (tactical and strategic) there is a shortage of books on Domain-Driven Design. So when I understood Vaugh Vernon's new book was intended as an addition to the series, I set out to read it to get yet another perspective on DDD patterns and a new set of examples. Incidentally, here's a review for the ones of you that are thinking about reading book.

Format

First of all, let's get out of the way questions on the format of the book. I read the Kindle version, so not a paper one, but has been organized neatly as code is always well-formatted and figures and diagrams get their own page where they can be viewed in a unique shot. The Kindle version however (like for other technical titles) makes you overestimate the length of the book, since the last 20% of the completion bar is just an index of the terms.

While the book is cleanly divided into chapters by pattern (Entity, Value Object, Domain Events...), there are some inserted comics called Cowboy Logic instanceof AmericanHumor. They may entertain you in Texas, but most of them made no sense to me as a non-native English speaker Italian who never lived in the US.

Some unique things I've learned

• how linguistic boundaries can help define Bounded Context with respect to sticking to the walls that are in place between your existing applications.
• Ubiquitous Languages are per-Bounded Context
• different categories of Repositories and approaches to persistence
• Identity generation strategies, from natural keys to RDBMS auto-incremented fields and UUIDs.
• Aggregate design, explaining how to cut between these clusters of objects and how to make them talk with each other.
• a full treatment of Domain Events, their storage and transmission to other Bounded Contexts to limit the scope and time of transactions. This was just marginal in Evans's original DDD book, and it's nice Vernon has collected and distilled the various experiences of the community and put them together here. Event Sourcing will still need additional learning with respect to this book.

You will probably learn other unique things with respect to me, since your personal experience with DDD is different. Your list will not match this one but I trust it will be long.

Some confirmations

Some of the concepts I read in the book were confirmations of something I suspected or gained from experience. Here are some examples:

• DDD targets simpler models, not more complex ones, with respect to a plain solution written in an object-oriented way (heard me, ApplicationPersistedEntityBeanServiceFactory classes?)
• The code is the design, and it can be developed iteratively and test-first; "ceremonious, up-front design" is not cherished by this approach.
• a Domain is what an organization does and the world it does it in: I struggled to find a clear definition of this term.
• Alignment of Subdomains and Bounded Context is desirable: if your applications map to deparments, Conway's law* will act in their favor instead of trying to teat them apart.
• The majority of Aggregates are just a Root Entity plus some contained Value Objects. Cut your object model as much as possible into different aggregates, as transactions shouldn't span more than one of them.
• Referencing of Aggregate from other Aggregates is dangerous because it lets inadvertent" writes propagate to the referenced objects. Referencing by identity alone forces the encapsulation of write but requires a different mechanism for reading (e.g. CQRS).

Some caveats

The book is Java centered: you have to be able to read Java to understand any code sample. Shouldn't be a problem as it is a sort of lingua franca, but there is also some tie-in to frameworks and their annotations such as @Transactional. This lets the author cut boilerplate code, but may require an explanation.

Applying all this stuff to an existing situation is impossible: the concept of book porn applies. For example, it's tempting to just trying to redesign your applications to work with 90% of the patterns described here, but you should first select* which patterns will make the design simpler and which can be realistically refactored in during a less-than-geologic amount of time. Pick your battles and your Core Domains.

The book uses an application modelling Scrum as its main example. While it involves non-technical people as project managers, I felt some kind of domain nausea after a while of submerging* in this domain, which is also not as stable and clearly defined as other ones. I prefer non-software domains such as the Cargo in Evans's book or in any case a domain where I know very little (to exercise discovery) to be more realistic. I understand these domains may not be well-fit for a book's length and format.