Domain-Driven Design

Start the DDD track

This folder is a study guide for Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans, 2003). It is not a reprint. The book is ~400 pages of argument, stories, and diagrams; these pages teach the same moves in original notes you can drill.

There is no word budget on this site. Early versions of this track were short on purpose (one idea + one drill). This version is meant to make you dangerous with the material: you should be able to run a modeling conversation, place a rule in the right layer, draw a context map, and argue about core vs generic without waving at “we should do DDD.”

When you finish you should be able to:

• Crunch messy expertise into a small model that predicts, then keep learning
• Keep one language in speech, tests, and types inside a boundary
• Isolate domain logic from UI, application, and infrastructure
• Express the model as entities, values, services, modules, aggregates, factories, repositories
• Deepen the model by naming what was implicit and making the design supple
• Protect integrity with bounded contexts, a map, and honest integration patterns
• Distill a core domain and give the rest of the system a cheaper job

Work in order. Parts I–II without III–IV is a catalog of nouns. Parts III–IV without I–II is strategy theater.

How to use this with the book

1. Skim the matching chapter in Evans (titles are in Further reading on each page).
2. Do the drill out loud. The drills are the point.
3. Steal the moves, not the cargo-shipping case. Examples here use a generic consumer product: identity, experiments, messaging, onboarding.

If a page still feels thin next to the chapter, that is a cue to open the book, not a sign the site ran out of space.

The four parts (Evans’s structure)

1. Put the model to work — knowledge, language, bind to code.
2. Building blocks — isolation and the object life cycle.
3. Deeper insight — breakthroughs, implicit→explicit, supple design, patterns, how teams refactor.
4. Strategic design — integrity across teams, distillation, large-scale structure.

Lessons

01 Knowledge crunchingPCB-nets style: you will not become the expert; you will distill with them.

02 Ubiquitous languageEvery medium: talk, tests, code, diagrams. Translation tax is a design bug.

03 Bind model to codeHands-on modelers. If it is not in the running software, it is not the model.

04 Isolate the domainFour layers, smart UI as a real choice, how rules leak into widgets and SQL.

05 Entities, values, servicesIdentity vs attributes vs verbs. Associations that will not survive implementation.

06 Life cycleAggregates, factories, repositories, and the transaction boundary.

07 Walk a modelEnd-to-end slice, then one unplanned feature that stresses the boundary.

08 Make the implicit explicitListen, mine contradictions, name policies and specs, catch a cascade.

09 Supple designIntention, purity, assertions, contours, closure, declarative style.

10 Patterns in the modelAnalysis patterns and GoF patterns as domain language, not costume.

11 Refactor toward insightHow a team actually gets a deeper model without a big-bang rewrite.

12 Bounded contextsIntegrity is a boundary. Context map and the integration catalog.

13 Distill the coreVision, generic subdomains, where to spend stars.

14 Large-scale structureEvolving order, responsibility layers, who owns the map.