Domain-Driven Design book
The foundational text on aligning software design with the business domain. The 'Blue Book.'
The foundational text on aligning software design with the business domain. The 'Blue Book.'
why it matters
DDD is the framework most modern microservice and platform thinking is built on, even when teams don't realize it. Bounded contexts, ubiquitous language, anti-corruption layers — these are now baseline architectural vocabulary. Evans's original treatment is dense but worth wrestling with; the strategic-design half is more important than the tactical-patterns half.
key ideas
- Strategic design: bounded contexts, context maps, core domain vs supporting subdomains. Most of the value is here.
- Tactical design: aggregates, entities, value objects, repositories, factories. The implementation half people often start with and lose the strategic frame.
- Ubiquitous language: code, conversation, and docs use the same words for the same things — drift is a model bug, not a translation bug
- Anti-corruption layer: protect your domain from foreign models you don't control
- Distillation: identify the core domain, invest your best people there, generic-ify the rest
memorable framings
- 'The model and the heart of the design shape each other.'
- 'Modeling is an activity that doesn't end with the writing of code.'
who should read it
Senior engineers who are starting to make architecture decisions. Skip to strategic design first if the tactical patterns feel pedantic — most teams misuse DDD by stopping at tactical.