Module 3: Domain-Driven Design & Bounded Contexts
Primary text: Learning Domain-Driven Design (Vlad Khononov)
Selective support: Fundamentals of Software Architecture for service-boundary framing, Clean Architecture for layer discipline around the domain, API Design Patterns (Geewax) for integration-language references, Just Enough Software Architecture for framing only
This guide is the primary teacher. You do not need to read the source books front-to-back. You do need to leave this module able to identify subdomains, draw bounded contexts on a real system, design an aggregate that holds its invariants, and connect the domain model to the services and APIs that carry it.
Scope of This Module
Domain-driven design is where domain knowledge stops being a slide deck and starts controlling your architecture, your APIs, and your team boundaries.
What it covers in depth:
- the three-level split: business domain, subdomain, bounded context
- core / supporting / generic subdomains and why the distinction changes your design
- ubiquitous language as a per-context constraint, not an org-wide glossary
- partnership, customer-supplier, and conformist relationships between contexts
- anticorruption layer, open host service, and published language
- drawing a context map you could actually defend in a review
- EventStorming at big-picture, process-level, and software-design levels
- domain message flow and heuristics for finding boundaries
- how and when bounded contexts must shift as the domain evolves
- entities, value objects, and aggregates with the one-transactional-boundary rule
- domain events as the language of change across aggregates and contexts
- repositories, factories, and the application layer orchestrating the domain
- CQRS and its relationship to DDD
- event sourcing: when it earns its complexity and when it does not
- services per bounded context: aligning architecture to the domain
What it deliberately does not cover:
- hexagonal / onion / clean-architecture mechanics as a separate track (S7M2)
- full saga and process-manager implementation (touched, deeper in S8)
- CQRS read-model infrastructure details (links only)
- microservice deployment, service mesh, and runtime topology (S8)
Before You Start
Answer closed-book:
- Why would two teams call the same entity by the same name but mean different things, and what does that cost in code?
- Give one plausible difference between a
core subdomainand asupporting subdomainin a streaming-music company. - What is the difference between an entity, a value object, and an aggregate?
- Why would you refuse to modify two aggregates in the same database transaction?
- What goes wrong if service boundaries are drawn by "team ownership of tables" instead of by bounded contexts?
Diagnostic Interpretation
4-5 solid answers - Ready for the full path.
2-3 solid answers - Continue, but expect extra time in Clusters 2 and 4.
0-1 solid answers - Re-read S7M2 modular monolith vs microservices briefly; DDD patterns are easier when modularity intuition is already there.
What This Module Is For
Most teams discover DDD after their system has already become a "big ball of mud." Throughout the program you will face questions like:
- where exactly should we split this monolith?
- why does the same word mean two incompatible things across our services?
- this aggregate has 40 fields and a 2,000-line class - is that the point?
- our two services are "decoupled" but one change needs a deploy of both - what did we miss?
- should we use event sourcing here, or are we about to buy years of accidental complexity?
This module builds the modeling reasoning needed for:
- API contract design (S7M4) - every API crosses a bounded context
- ADR writing (S7M5) - most architecture decisions are really domain-boundary decisions
- microservices topology (S8M2) - service boundaries should be domain boundaries
- event-driven architecture (S8M3) - domain events are the payloads that cross contexts
Concept Map
How To Use This Module
Work in order. Strategic design (Clusters 1-3) has to be stable before tactical design (Cluster 4) is useful. Cluster 5 depends on both.
We use a recurring case across the module: Parcel Shipping Co., a mid-size logistics platform that sells shipping labels, orchestrates carrier handoffs, tracks parcels, and bills customers monthly. A second case (Conference Ticketing) appears occasionally for contrast. You will refer to these cases inside concept pages and practice pages.
Cluster 1: Strategic Design Foundations
| Order | Concept | Type | Focus |
|---|---|---|---|
| 1 | Domain, Subdomain, Bounded Context: The Three-Level Split | PRIMARY | The three layers of strategic design and why each exists |
| 2 | Core, Supporting, and Generic Subdomain Classification | PRIMARY | How to classify a subdomain and why classification changes design |
| 3 | Ubiquitous Language Inside a Bounded Context | PRIMARY | Language as a per-context constraint, not an org glossary |
Cluster mastery check: For Parcel Shipping Co., can you list the business domain, at least five subdomains with types (core/supporting/generic), and propose at least three bounded contexts with a one-sentence language statement each?
Cluster 2: Context Mapping
| Order | Concept | Type | Focus |
|---|---|---|---|
| 4 | Relationships Between Contexts: Partnership, Customer-Supplier, Conformist | PRIMARY | Six collaboration patterns and when each applies |
| 5 | Anticorruption Layer, Open Host Service, and Published Language | PRIMARY | The three translation patterns and where they belong |
| 6 | Drawing a Context Map | PRIMARY | Producing a map that another architect can read and challenge |
Cluster mastery check: Given a system with six bounded contexts, can you draw a labeled context map showing the relationship on every edge and defend each choice?
Cluster 3: Discovering the Domain
| Order | Concept | Type | Focus |
|---|---|---|---|
| 7 | EventStorming: Big-Picture, Process, Software Design Levels | PRIMARY | The three scales of EventStorming, the sticky legend, and the flow |
| 8 | Domain Message Flow and Heuristics for Finding Boundaries | PRIMARY | Heuristics for where boundaries actually belong |
| 9 | Evolving Contexts: When Boundaries Must Shift | SUPPORTING | How and why bounded contexts change over time |
Cluster mastery check: Can you run a simulated big-picture EventStorming on a new domain in under 45 minutes and produce aggregate and context candidates?
Cluster 4: Tactical Building Blocks
| Order | Concept | Type | Focus |
|---|---|---|---|
| 10 | Entities, Value Objects, Aggregates: One Transactional Boundary Rule | PRIMARY | The building blocks and the non-negotiable transactional rule |
| 11 | Domain Events: Language of Change | PRIMARY | Events that express what happened, not what to do next |
| 12 | Repositories, Factories, and the Application Layer | PRIMARY | The plumbing that keeps the domain model clean |
Cluster mastery check: Can you sketch an aggregate (root + inner entities + VOs + invariants) for an unfamiliar feature and defend its transactional boundary?
Cluster 5: DDD in Practice
| Order | Concept | Type | Focus |
|---|---|---|---|
| 13 | CQRS and Its Relationship to DDD | SUPPORTING | Command/query separation as an implementation style |
| 14 | Event Sourcing: When It's Right, When It's Overkill | PRIMARY | Why to adopt event sourcing and why not to |
| 15 | Architecture-to-Context Alignment: Services Per Bounded Context | PRIMARY | Mapping contexts to services, databases, and deployments |
Cluster mastery check: Given a bounded-context map, can you propose a service decomposition with ownership, database-per-context, and integration style per edge?
Then work these practice pages:
| Order | Practice path | Focus |
|---|---|---|
| 1 | Strategic Design Lab | Subdomain discovery, classification, context sketching |
| 2 | Context Mapping Workshop | Drawing, labeling, and defending context maps |
| 3 | EventStorming Clinic | Facilitated EventStorming at three levels |
| 4 | DDD Tactical Katas | Aggregate design, domain events, and boundary-defense drills |
Use Module Quiz after the concept and practice path. Use Reference and Selective Reading and Learning Resources only for targeted reinforcement.
Learning Objectives
By the end of this module you should be able to:
- Separate business domain, subdomain, and bounded context, and name one concrete example of each from an unfamiliar business.
- Classify a subdomain as core, supporting, or generic with a written rationale, and choose a modeling style appropriate to each class.
- Write a ubiquitous language statement for a bounded context that is both consistent internally and obviously different from the next context.
- Identify which of the six integration patterns (partnership, shared kernel, customer-supplier, conformist, ACL, OHS/published language, separate ways) applies to a given bounded-context edge.
- Draw a context map for a non-trivial system and defend the relationship on every edge.
- Facilitate a big-picture EventStorming session and explain how to escalate to process-level or software-design levels.
- Apply at least four heuristics for finding bounded-context boundaries from a domain message flow.
- Design an aggregate (root, inner entities, value objects, invariants) that holds a strong-consistency rule without modifying other aggregates in the same transaction.
- Distinguish a domain event from a command and from an integration event, and write the event payload for a real business change.
- Describe the role of repositories, factories, and the application layer, and justify where each lives relative to the domain model.
- Decide whether CQRS or event sourcing is justified for a specific bounded context, with a written defense.
- Align services, databases, and deployment boundaries to bounded contexts, and recognize common misalignments.
Outputs
- one strategic-design packet for a non-trivial domain: subdomains, classifications, and at least three bounded contexts with language statements
- one rendered context map (ASCII or Mermaid) with labeled integration patterns on every edge
- one EventStorming artifact from a big-picture session, with sticky legend, pivotal events, and at least one aggregate candidate
- one aggregate design with root, inner entities, value objects, and explicit invariants
- one domain-event catalog with at least six events for a real feature, including payload shape and emission rules
- one application-service sketch showing repository use, transaction boundary, and error handling
- one CQRS-or-not decision memo and one event-sourcing-or-not decision memo, each 1 page
- one architecture-to-context alignment diagram showing services, databases, and ownership per context
- a mistake journal naming at least 8 recurring modeling errors (
anemic aggregate,cross-aggregate transaction,shared database across contexts,CRUD language leaking into core subdomain, etc.)
Completion Standard
You have completed Module 3 when all of these are true:
- you can sketch a domain -> subdomain -> bounded-context decomposition for an unfamiliar business in under an hour and defend every boundary
- you can look at an integration between two contexts and pick from the six patterns with a written reason
- your aggregate designs do not silently assume multi-aggregate transactions
- your domain events are named in past tense, carry the data the event describes, and do not command another context to act
- you can tell when CQRS or event sourcing is warranted and when it is over-engineering
- you can point at a service boundary in a real system and say whether it aligns with a bounded context
- your mistake journal contains real mistakes, not generic ones
If the answer looks right but you cannot say which bounded context a feature belongs to or which subdomain class it represents, the module is not complete.
Reading Policy
- Concept pages are the main path.
- Local book chunks from Learning Domain-Driven Design are the primary selective reinforcement.
- External URLs (
dddcommunity.org,domainlanguage.com,vaughnvernon.com,eventstorming.com,dddheuristics.com) are permitted and cited inresources.md. Read only if stuckmeans try the concept page, self-check, and drill first.- Sketched context maps, aggregate diagrams, and EventStorming outputs are required deliverables, not optional enrichment.
Suggested Weekly Flow
| Day | Work |
|---|---|
| 1 | Concepts 1-3, write the subdomain list for Parcel Shipping Co. |
| 2 | Concepts 4-5, classify each known integration between two teams you have seen |
| 3 | Concept 6 and Practice 2 partial: sketch context map v1 |
| 4 | Concepts 7-8, run a simulated big-picture EventStorming on an unfamiliar case |
| 5 | Concept 9 and Practice 3 |
| 6 | Concepts 10-11, design one aggregate and its domain events |
| 7 | Concept 12 and Practice 4 kata 1 |
| 8 | Concepts 13-14, write both decision memos |
| 9 | Concept 15 and Practice 1 |
| 10 | Practice 4 remaining katas, quiz, mistake-journal pass |
Reference
If you need exact links into the local chunked books, use Reference and Selective Reading.
Rich Learning Pages
Worked Examples | Guided Labs | Case Studies | Mistake Clinic | Reading Guide | Capstone Thread