Learn Domain-Driven Design: The Best Books, in Order
This curriculum builds a rigorous, practitioner-grade mastery of Domain-Driven Design starting from intermediate software knowledge. It moves from DDD's core philosophy and vocabulary, through strategic and tactical patterns, into advanced architectural integration and real-world modeling techniques — each stage equipping you with the mental models needed to tackle the next.
DDD Foundations
IntermediateUnderstand the core philosophy of DDD — ubiquitous language, the domain model, and the essential building blocks (entities, value objects, aggregates, repositories, services) — so you can speak and think in DDD terms.
▸ Study plan for this stage
Pace: 8–10 weeks, ~25–30 pages/day (Vernon's Distilled first: 2–3 weeks; Evans' DDD second: 5–7 weeks)
- Ubiquitous Language: using the same terminology across code, design, and business conversations to eliminate translation gaps
- Domain Model: a structured representation of the problem space that captures business rules and logic, not just a data model
- Entities: objects with identity that persist over time and whose lifecycle matters to the domain
- Value Objects: immutable objects defined by their attributes, not identity, used to model concepts like Money or Address
- Aggregates: clusters of entities and value objects treated as a single unit with clear boundaries and a root entity for consistency
- Repositories: abstractions that provide collection-like access to aggregates, hiding persistence details
- Domain Services: stateless operations that don't naturally belong to an entity or value object but are essential to the domain
- Bounded Contexts: explicit boundaries within which a ubiquitous language and model are consistent, enabling large systems to scale
- What is ubiquitous language and why is it critical to DDD? How does it differ from technical jargon?
- Explain the difference between an entity and a value object. When would you use each in a domain model?
- What is an aggregate and what role does the aggregate root play in maintaining consistency?
- How do repositories differ from DAOs (Data Access Objects) and why does DDD treat them as domain abstractions?
- When should you use a domain service versus putting logic on an entity or value object?
- What is a bounded context and how does it help structure large, complex domains?
- Read Vernon's Distilled (Chapters 1–5) and create a one-page summary of ubiquitous language with a concrete example from a domain you know (e.g., e-commerce, healthcare, banking).
- Model a simple domain (e.g., an online bookstore or library) by identifying entities, value objects, and aggregates; draw a diagram showing boundaries and relationships.
- Refactor a legacy codebase snippet or your own past project to extract a domain service; document why the logic doesn't belong on an entity.
- Read Evans' DDD (Part I & II: Chapters 1–11) and write a 2–3 page reflection on how ubiquitous language and the domain model differ from traditional layered architecture.
- Design a repository interface for an aggregate from your modeled domain; write pseudocode showing how it abstracts persistence without leaking database details.
- Conduct a 'language workshop' exercise: take a real domain (your workplace, a hobby, or a case study) and collaboratively define 10–15 key terms that form the ubiquitous language; document conflicts and resolutions.
Next up: Mastering these foundations equips you to tackle the next stage—applying DDD to real architecture—where you'll learn how to organize code using layered architecture, handle inter-aggregate communication, and manage bounded context integration at scale.
A concise, modern on-ramp to DDD's most important ideas. Read this first to build vocabulary and intuition before tackling the denser canonical texts.
The original 'Blue Book' that defined the field. Now that you have the distilled overview, you can absorb Evans' deep reasoning, nuance, and the full pattern language without getting lost.
Strategic Design & Bounded Contexts
IntermediateMaster strategic DDD — bounded contexts, context maps, subdomains, and how to carve large systems into coherent, independently evolvable parts.
▸ Study plan for this stage
Pace: 4–5 weeks, ~40–50 pages/day (focusing on Parts 2–3 of Millett's book covering strategic design, bounded contexts, and context mapping)
- Bounded Contexts: logical boundaries that define where a ubiquitous language applies and how domain models are isolated from one another
- Subdomains: the problem space divisions (Core, Supporting, Generic) that help identify which parts of the business are strategically important
- Context Maps: visual and relational tools for documenting how bounded contexts interact, including patterns like Shared Kernel, Customer-Supplier, and Anticorruption Layer
- Strategic Design: the high-level architectural decisions that determine how to partition a large system into manageable, independently evolvable pieces
- Ubiquitous Language at Scale: how language boundaries shift across contexts and why translation mechanisms are necessary between them
- Organizational Alignment: how team structure, communication, and Conway's Law influence bounded context design
- Integration Patterns: practical approaches (Anticorruption Layer, Facade, Event-driven) for connecting disparate bounded contexts
- What is a bounded context and why is it essential to separate the ubiquitous language within one context from another?
- How do you distinguish between Core, Supporting, and Generic subdomains, and why does this classification matter for strategic planning?
- What is a context map and what are the main relationship patterns (e.g., Shared Kernel, Customer-Supplier, Anticorruption Layer) you can use to document how bounded contexts interact?
- How does Conway's Law inform bounded context design, and what role does team structure play in defining context boundaries?
- When should you use an Anticorruption Layer versus a Shared Kernel, and what are the trade-offs?
- How do you identify and validate bounded context boundaries in a large, complex domain?
- Map a real or hypothetical large system (e.g., an e-commerce platform, SaaS product) into 3–5 bounded contexts; justify each boundary based on business capability, team structure, or language differences
- Create a context map for your chosen system showing at least 4 different relationship patterns between contexts; document the rationale for each relationship type
- Classify the subdomains in your system as Core, Supporting, or Generic; explain why each classification affects investment and team allocation
- Design an Anticorruption Layer for one context that must integrate with a legacy or external system; document the translation logic and failure modes
- Refactor a monolithic domain model (or pseudocode) into multiple bounded contexts with separate ubiquitous languages; highlight the translation points
- Conduct a 'team structure audit' for your system: identify how current team boundaries align (or misalign) with proposed bounded contexts, and propose adjustments
Next up: This stage equips you with the strategic vocabulary and patterns to decompose complex domains; the next stage will deepen your ability to implement these boundaries through tactical DDD patterns (Aggregates, Repositories, Domain Events) and event-driven architecture.
Broadens strategic thinking with real-world case studies and shows how bounded contexts integrate with modern architectures, reinforcing and extending what Vernon covers.
Architecture & Microservices Integration
ExpertApply DDD strategically at the system architecture level — mapping bounded contexts to microservices, managing distributed consistency, and integrating DDD with modern architectural styles.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day (mix of reading and reflection)
- Mapping bounded contexts to microservice boundaries and identifying service seams
- Managing distributed consistency and eventual consistency trade-offs across services
- Decomposing monoliths: strangler pattern, database per service, and shared database anti-patterns
- Inter-service communication: synchronous vs. asynchronous patterns and their DDD implications
- Service ownership and organizational alignment (Conway's Law applied to microservices)
- Handling cross-cutting concerns: transactions, saga patterns, and distributed tracing in DDD contexts
- Versioning, backwards compatibility, and contract-driven design between bounded contexts
- Observability and monitoring strategies for distributed DDD systems
- How do you identify the right boundaries for microservices using DDD bounded contexts, and what are the consequences of choosing boundaries incorrectly?
- What are the trade-offs between synchronous and asynchronous communication patterns when integrating microservices, and how does each affect your domain model?
- Describe the strangler pattern and explain how it enables gradual migration from a monolith while maintaining DDD principles.
- Why is 'database per service' important for microservice independence, and what challenges does it create for maintaining consistency across bounded contexts?
- How does Conway's Law apply to microservice architecture, and what organizational changes might be needed to align teams with service boundaries?
- What is a saga pattern, and how does it help manage distributed transactions across multiple bounded contexts?
- Map a real or fictional monolithic application into bounded contexts using DDD principles, then propose microservice boundaries aligned with those contexts.
- Design the communication contract (events, commands, or API endpoints) between two microservices representing different bounded contexts; document versioning and backwards compatibility strategies.
- Implement a simple strangler facade that routes requests between a legacy monolith and a new microservice, demonstrating gradual migration.
- Model a distributed transaction scenario (e.g., order processing across inventory and payment services) using the saga pattern; compare orchestration vs. choreography approaches.
- Create an observability plan for a multi-service DDD system: define domain events to emit, logging boundaries, and tracing strategies across service calls.
- Refactor a shared database schema into separate databases per service; identify and resolve data consistency challenges using eventual consistency and event sourcing.
Next up: This stage equips you to architect large-scale systems where DDD principles guide service decomposition and integration; the next stage will deepen your ability to handle advanced tactical patterns, event sourcing, and CQRS within those distributed contexts.
The definitive guide to microservices architecture; read here to see how bounded contexts translate directly into service boundaries and how DDD strategy governs system decomposition.
Focuses on the real-world migration path, using DDD concepts like seams and bounded contexts as the primary tool for safely decomposing existing systems — essential for practitioners working with legacy codebases.
Advanced Patterns & Synthesis
ExpertSynthesize everything into a mature, nuanced practice — understanding how to balance DDD investment, apply heuristics under real constraints, and think about software design at a philosophical level.
▸ Study plan for this stage
Pace: 6–8 weeks, ~25–30 pages/day, with 2–3 days per week reserved for reflection and synthesis exercises
- Balancing DDD investment: knowing when to apply tactical patterns, when to apply strategic patterns, and when DDD overhead is not justified
- Heuristics for bounded context design: using business capability, organizational structure, and technical constraints to define boundaries pragmatically
- Complexity as the core design problem: recognizing deep vs. shallow modules, and how DDD addresses accidental vs. essential complexity
- Philosophical foundations of software design: understanding that design is about managing dependencies, reducing cognitive load, and enabling change
- Integrating DDD with Ousterhout's principles: applying domain models within the framework of information hiding, interface design, and working-code-first philosophy
- Red flags and anti-patterns: recognizing over-engineering, premature abstraction, and when to refactor domain models
- Practical synthesis: making trade-off decisions between purity, pragmatism, and team capability in real projects
- When should you invest in a rich domain model versus a simpler CRUD-based design, and what are the decision criteria?
- How do you define bounded contexts in a real system where organizational structure, technical constraints, and business capability all pull in different directions?
- What is the relationship between Ousterhout's concept of 'deep modules' and DDD's strategic patterns (bounded contexts, ubiquitous language)?
- How do you recognize when a domain model has become over-engineered, and what refactoring strategies does Khononov recommend?
- Describe a scenario where DDD would add more complexity than value, and explain how you would approach design differently in that case.
- How do information hiding and interface design (Ousterhout's principles) inform the design of aggregate boundaries and domain events?
- Audit a real or past project: map its current domain model (or lack thereof) against Khononov's heuristics. Identify where DDD investment was justified and where it was not.
- Design bounded contexts for a moderately complex system (e.g., an e-commerce platform, SaaS product) using both Khononov's business-capability approach and Ousterhout's deep-module principle. Compare the results.
- Refactor a shallow, over-engineered domain model: identify unnecessary abstractions, simplify aggregates, and document the trade-offs made.
- Write a design philosophy statement for a real team or project: articulate when and how DDD applies, what complexity is essential vs. accidental, and what your team's non-negotiable design principles are.
- Conduct a 'complexity archaeology' exercise: take a legacy codebase, identify where complexity accumulated, and propose a DDD-informed refactoring strategy that respects Ousterhout's principle of working code first.
- Debate exercise: pair up and argue both sides—when is DDD worth the investment, and when is it over-kill? Use concrete examples from Khononov and Ousterhout to support each position.
Next up: This stage equips you with the judgment to apply DDD and software design principles contextually, setting the foundation for either specialized deep-dives (e.g., event sourcing, CQRS, microservices architecture) or leadership roles where you guide architectural decisions across teams and systems.
A modern synthesis that revisits all DDD concepts with fresh clarity, corrects common misconceptions, and provides decision heuristics for when and how to apply each pattern — the ideal capstone read.
Zooms out to first principles of managing complexity in software; reading this last sharpens your judgment about what DDD is truly solving and how to apply it with wisdom rather than dogma.
Discussion
Keep reading
Paths that share books, cover the same subject, or open a related topic.
