One vocabulary.
Entity.
Value Object.
Aggregate.
Bounded Context.
Ubiquitous.
Domain-Driven Design says the hardest part of software is the domain, not the technology. This course teaches you to model it — strategic boundaries first, tactical objects second — through one bookstore order-fulfillment example that runs from Module 1 to Module 8.
The bookstore's context map — built across Modules 3–5
One principle runs under every module: the model is one vocabulary, shared by code and conversation.
When the word in the meeting and the word in the method name mean the same thing — with the same rules attached — the model is working. When they drift apart, bugs follow, not because anyone made an obvious mistake, but because the code stopped meaning what the business thinks it means. This course teaches you to build that correspondence on purpose: a Ubiquitous Language you can write down, Bounded Contexts where it holds without ambiguity, and tactical objects — Entities, Value Objects, Aggregates — that express it faithfully in Java.
Eight modules, in order
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.
Open moduleThe 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.
Open moduleDomains & Subdomains
Where to spend your modeling effort: Core, Supporting, and Generic subdomains, and how to tell them apart.
Open moduleBounded 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.
Open moduleContext Mapping
Bounded Contexts don't live in isolation. A Context Map names exactly how they relate — technically and politically — using nine recognized patterns.
Open moduleEntities & 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?
Open moduleAggregates & 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.
Open moduleDomain 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.
Open moduleThe course content lives as Markdown and is rendered straight onto this site — one source of truth, no copies. It's adapted from a DDD reference specification grounded in Eric Evans and Vaughn Vernon's work, restructured into a beginner-to-advanced curriculum.
How this was built