Key Principle
DDD adoption follows a specific sequence: strategic design first, tactical design second, with Event Storming as the bridge between them. Skipping or inverting this sequence produces the problems DDD is designed to prevent.
Why This Matters
Teams commonly attempt DDD by jumping to tactical patterns (Aggregates, Domain Events) without establishing strategic foundations (Bounded Contexts, Ubiquitous Language). This produces sophisticated technical patterns disconnected from business reality — a well-structured Big Ball of Mud.
Phase 1: Strategic Foundation
1. Identify your Core Domain
- Use Subdomain classification: what is Core (differentiator), Supporting (custom but non-differentiating), Generic (commodity)? (Chapter 3)
- If you're building something you could buy, it's not Core
- Core Domains get the best developers and deepest modeling investment
2. Establish Bounded Context boundaries
- One Bounded Context per Core Domain, ideally 1:1 with Subdomains (Chapter 2-3)
- One team per Bounded Context, one repository per Bounded Context (Chapter 2)
- Use the "Challenge and Unify" method to filter concepts: if the word doesn't belong in the core language, the concept doesn't belong in the model (Chapter 2)
3. Develop the Ubiquitous Language
- Write concrete scenarios with Domain Experts (not use cases or user stories) (Chapter 2)
- Challenge with "who," "what constraints," and "who needs to know" questions
- The language IS the design artifact — code must speak the same language
4. Map Context relationships
- Identify which mapping pattern applies to each boundary crossing (Chapter 4)
- Default to Anticorruption Layer when integrating with legacy or external systems
- Choose messaging over RPC/REST for inter-context communication
Phase 2: Tactical Modeling
5. Run Event Storming sessions
- Sequence: Domain Events (orange) → Commands (light blue) → Aggregates (pale yellow) → Boundaries (Chapter 7)
- 2-3 hour sessions over 3-4 days with Domain Experts and developers
- Track modeling debt from timeboxed sessions explicitly
6. Design Aggregates
- Start with single-Entity Aggregates; grow only when invariants demand it (Chapter 5)
- Ask Domain Experts about time tolerances: "how much time may elapse before X must react to Y?" (Chapter 5)
- Default to eventual consistency between Aggregates
7. Implement Domain Events
- Name as past-tense verbs; include command-derived properties (Chapter 6)
- Persist Aggregate and Domain Events atomically
- Consider Event Sourcing for Core Domains requiring complete audit history
Common Execution Pitfalls
- Skipping strategic design: Jumping to Aggregates without Bounded Contexts produces technically sophisticated mud (Chapter 1)
- Substituting Product Owner for Domain Expert: A PO manages backlogs; a Domain Expert possesses deep business knowledge. Substituting one for the other severs the language from its source of truth (Chapter 2)
- Treating modeling as overhead: "Knowledge acquisition is both a Scrum tenet and a major goal of DDD but is largely ignored in exchange for relentless delivery with Scrum." (Chapter 7). Modeling IS delivery.
- Uniform investment: Applying the same modeling effort to Core, Supporting, and Generic Subdomains wastes resources on non-differentiating work (Chapter 3)
- Immediate consistency by default: Business stakeholders influenced by database thinking demand everything be immediately consistent. Larger transactional boundaries cause more conflicts, producing less consistency in practice (Chapter 5)
Key Quotes
"You really cannot apply tactical design in an effective way unless you begin with strategic design." — Vaughn Vernon, Chapter 1
"Design is inevitable, and either you will do poorly as a result of bad design, or you will succeed by delivering with an effective design." — Vaughn Vernon, Chapter 7
Related References
- The Core Framework: Strategic Before Tactical - The thesis driving this sequence
- Event Storming - The bridge between strategic and tactical
- Rules of Thumb - Quick heuristics for each phase