Domain-Driven Design, audited

Eric Evans published Domain-Driven Design in 2003. Twenty years of practice grew up around it: Vernon, Khononov, Millett and Tune, Fowler, Brandolini, Young, Dahan, Skelton and Pais, Newman, Wlaschin. This garden’s Domain-Driven Design reads the Blue Book the way it reads any source: cross-checked against that field, with Evans as a source and not an authority. The audit mostly vindicates him, but not by deference. The field did not defer to the book. It converged onto his strategic core, extended rather than overturned him, and where a 2003 assumption expired, Evans had usually flagged it first.

The core is strategic, and that is Evans’s own verdict

The durable center of DDD is its strategic design: bounded contexts, ubiquitous language, context mapping, and the distillation of a core domain. This is cross-author consensus, and it is not a later reinterpretation. Evans began the reweighting himself: as early as 2009 he was telling conference audiences that the tactical building blocks had been over-emphasized and that the core-domain material, buried late in the book, deserved far more weight. Millett and Tune open their book by naming “tactical patterns are key to DDD” as the first misconception to unlearn.

One model, one language, one boundary. Cross a boundary and you translate; you don’t share.

The cheapest and most robust pattern in the whole audit is ubiquitous language, and its robustness is demonstrable rather than asserted: domain terms appear verbatim as class and method names, with no translation layer between the people who know the domain and the code that runs it.

Every pattern is an intent wrapped around a mechanism

The lens the audit kept returning to: each DDD pattern is a durable intent wrapped around a dated mechanism. The intent is what the pattern is for; the mechanism is how 2003 had you deliver it. The intent survives every technology shift; the mechanism is the part that ages. A bounded context is almost pure intent, so it came through object-orientation, ORMs, distribution, and remote teams untouched. An aggregate is an intent (a consistency boundary) welded to a mechanism (one database transaction, one hand-rolled repository), so it looks dated even though its boundary idea is not. Read the book for its intents; get its mechanisms from the field that grew up around it.

The tactical building blocks are tiered, not flat

Treating Evans’s tactical patterns as one flat roster is the common mistake. They are not equal. At the top sit the entity and the value object, the two blocks never walked back: the 2015 Reference keeps both essentially verbatim, and the value object is the one mechanism in the whole audit that improved with age. Its intent predates the book (Ward Cunningham’s Whole Value, credited in Evans’s own footnotes; Fowler’s 2002 catalog named it first), and its 2003 mechanism, hand-written equality plus immutability by discipline, became a compiler guarantee in records and data classes. The field even tilts value-first: Vernon and Khononov both say to prefer value objects wherever possible, in part because “entity” was captured by ORMs and entities get overused. Below them, the Repository and the four-layer architecture are endorsed but superseded in mechanism: Evans himself pointed past four named layers toward hexagonal architecture in the 2015 DDD Reference, and even the Repository’s proponents catalog its hazards. Factory, Specification, and Smart UI are peripheral: Evans dropped Specification from the 2015 reference, hedged the “anti-pattern” label on Smart UI in the original text, and Factory survives mostly renamed. The honest line is not that tactical design is optional. Fowler praises the building blocks and Wlaschin’s book is mostly tactical. It is that tactical patterns earn their place by following from strategic decisions: choose your contexts and your core domain first, then reach for aggregates.

Domain events are the field’s addition, not Evans’s

The pattern the community most treats as core tactical DDD, the domain event, is barely in the Blue Book. Fowler’s 2005 write-up of it does not mention Evans; Dahan’s 2009 case for explicit domain events does not cite the book. Domain events are the field’s most successful addition to tactical DDD, built on a seam Evans left open. And they are not a bundle: a domain event, event sourcing, and CQRS are three distinct patterns with a one-way dependency between them. The “DDD plus CQRS plus event sourcing” package is a framework-marketing artifact, not a position the field’s authorities hold. The person who did most to popularize event sourcing warns against applying it to a whole system. The field’s other post-2003 addition is a working format rather than a pattern: Event Storming, Brandolini’s collaborative workshop, which the DDD canon later adopted from within.

What the core is not

The DDD community is not fractured at its center. The live disagreements are all about application, not the core: how big an aggregate should be, whether a domain object should hold behavior, whether a bounded context maps one-to-one to a microservice. Two of the loudest apparent controversies dissolve on inspection. Doing DDD in a functional language (Wlaschin, Ghosh) turns out to be mostly vocabulary, and “domain events versus event sourcing” is a distinction, not a fight. Nearby vocabularies overlap with Evans’s without replacing it: an anti-corruption layer is wider than a hexagonal adapter, and Team Topologies’ team boundaries are a complementary lens on the same ground a context map covers, not a rename of it.

What this audit refuses to do

It does not treat the 2003 book as scripture, and it does not pretend the concepts have aged. The accurate story is narrower and more interesting than either: Evans scoped the book tightly, modeling a known domain in a synchronous, single-transaction, co-located world, and pre-cut most of the seams the field later filled. Read the Blue Book for its intents; get its mechanisms from the twenty years of practice that followed.

Sources

Every claim above was checked against the field’s own writing, not against Evans as an authority: sources logged, verdicts recorded, disagreements mapped rather than smoothed over.

• Eric Evans, Domain-Driven Design Reference (2015): Evans’s own free summary of the 2003 Blue Book, and where he reweighted the strategic core and pointed past the four-layer architecture.
• Eric Evans, What I’ve Learned About DDD Since the Book (QCon London 2009): the talk where Evans himself began reweighting toward the strategic core, six years before the Reference.
• Vaughn Vernon, Implementing Domain-Driven Design (2013): the tactical mechanics, aggregates especially, worked out in code.
• Vaughn Vernon, Domain-Driven Design Distilled (2016): the compact, strategy-first restatement, and where Event Storming gets a chapter (“Acceleration and Management Tools”) as an acceleration tool for doing DDD.
• Vlad Khononov, Learning Domain-Driven Design (2021): the modern strategic-first restatement of the discipline.
• Scott Millett and Nick Tune, Patterns, Principles, and Practices of Domain-Driven Design (2015): names “tactical patterns are key to DDD” as the first misconception to unlearn.
• Martin Fowler, Domain Event (2005), Value Object (2002), and his DDD bliki: the domain-event write-up that never cites Evans, the value object named months before the Blue Book, and his defense of the building blocks.
• Ward Cunningham, The CHECKS Pattern Language (1994): Whole Value, the value object’s ancestor, credited in the Blue Book’s own footnotes.
• Alberto Brandolini, Introducing EventStorming: the workshop format, from the person who invented it.
• Mathias Verraes, Facilitating Event Storming (2013): an early facilitation account, down to photographing the wall and then throwing the model away to rebuild it the next day.
• Greg Young, Why Event Sourced Systems Fail: event sourcing’s chief popularizer warning against applying it to a whole system.
• Udi Dahan, Domain Events – Salvation (2009): the case for explicit domain events, also without citing the Blue Book.
• Matthew Skelton and Manuel Pais, Team Topologies (2019): team boundaries as a complementary lens on the ground a context map covers.
• Sam Newman, Building Microservices: where the bounded-context-to-service question actually gets argued.
• Scott Wlaschin, Domain Modeling Made Functional: functional DDD in full, which the audit finds is mostly vocabulary over the same intents.
• Debasish Ghosh, Functional and Reactive Domain Modeling (2016): the other functional-DDD source the audit reads the same way, as vocabulary over the same intents.
• Robert C. Martin, The Clean Architecture (2012): where “entity” names the enterprise-business-rules layer, a third sense distinct from the DDD entity and the ORM’s persistence entity.