Curriculum
Eight modules in three movements: get the foundational idea, learn to draw strategic boundaries, then build the tactical objects inside one of them. Read in order — each module leans on the language built in the ones before it.
Foundations
Why DDD exists, and the Ubiquitous Language that ties code to conversation.
Why Domain-Driven Design
The hardest part of software isn't the technology — it's mastering the complexity of the domain. DDD is a discipline for doing that on purpose.
The Ubiquitous Language
The shared, rigorous vocabulary that means the same thing in a business conversation and in a class name — and how to build a glossary that proves it.
Strategic Design
Divide the domain into subdomains, draw Bounded Contexts, and map how they relate.
Domains & Subdomains
Where to spend your modeling effort: Core, Supporting, and Generic subdomains, and how to tell them apart.
Bounded Contexts
The explicit boundary within which one model and one language hold unambiguously — and why the same word can mean two different things on either side of it.
Context Mapping
Bounded Contexts don't live in isolation. A Context Map names exactly how they relate — technically and politically — using nine recognized patterns.
Tactical Design
Inside one context: Entities, Value Objects, Aggregates, Repositories, Services, Events, and how it all assembles.
Entities & Value Objects
Every tactical pattern in DDD ultimately rests on one distinction: does this thing have an identity you must track through change, or is it defined purely by what it is?
Aggregates & Repositories
The most conceptually important — and hardest to recover — tactical pattern: a cluster of objects with one entry point, one consistency boundary, and exactly one repository.
Domain Services, Events & the Whole Picture
What to do with logic that doesn't belong to any one Entity, how to name a fact that already happened, and how all eight modules fit into one coherent model.