Domain-Driven Design: From Strategic Thinking to Bounded Contexts
Domain-Driven Design (DDD) is not a framework or a library. It is a set of principles for structuring software around business domains. In 2026, DDD remains the most reliable methodology for decomposing complex systems, especially when planning microservice boundaries.
DDD Concept Taxonomy
Domain-Driven Design
├── Strategic Design
│ ├── Bounded Context
│ ├── Ubiquitous Language
│ ├── Context Mapping
│ ├── Core / Supporting / Generic Subdomains
│ └── Domain Vision Statement
├── Tactical Design
│ ├── Entities
│ ├── Value Objects
│ ├── Aggregates (+ Aggregate Root)
│ ├── Domain Events
│ ├── Repositories
│ ├── Factories
│ └── Domain Services
└── Integration Patterns
├── Anti-Corruption Layer (ACL)
├── Shared Kernel
├── Open Host Service
├── Published Language
└── Customer-Supplier
Strategic vs Tactical Patterns
| Aspect | Strategic Patterns | Tactical Patterns |
|---|---|---|
| Scope | System-wide, cross-team | Within a single bounded context |
| Stakeholders | Architects, PMs, domain experts | Developers, tech leads |
| Output | Context maps, team boundaries | Code structure, domain model |
| When to apply | Before building anything | During implementation |
| Risk of skipping | Wrong service boundaries, expensive rework | Anemic domain model, logic leaks |
| Effort | Workshops, EventStorming sessions | Continuous refactoring |
| Reversibility | Low (organizational impact) | Medium (code-level changes) |
Context Mapping Diagram
┌──────────────┐ Shared Kernel ┌──────────────┐
│ Identity │◄───────────────────►│ Billing │
│ Context │ │ Context │
└──────┬───────┘ └──────┬───────┘
│ Open Host / Published Language │ Customer-Supplier
│ │
┌──────▼───────┐ Anti-Corruption ┌──────▼───────┐
│ Catalog │ Layer (ACL) │ Shipping │
│ Context │◄════════════════════│ Context │
└──────────────┘ └──────────────┘
│ Conformist │
│ │
┌──────▼───────┐ ┌──────▼───────┐
│ 3rd-Party │ │ Warehouse │
│ Search API │ │ Context │
└──────────────┘ └──────────────┘
Bounded Context Identification Checklist
| # | Question | Signal |
|---|---|---|
| 1 | Does this area have its own vocabulary? | Different terms = different context |
| 2 | Would a different team own this? | Organizational alignment matters |
| 3 | Does it have a distinct lifecycle? | Deploy independently = separate context |
| 4 | Do data consistency rules differ? | Strong vs eventual consistency |
| 5 | Is there a natural transaction boundary? | Aggregate boundaries indicate contexts |
| 6 | Would changing this break unrelated features? | Coupling signal |
| 7 | Does this subdomain provide competitive advantage? | Core vs supporting vs generic |
| 8 | Are there different read/write patterns? | CQRS candidate within the context |
Common Pitfalls
Entity obsession -- Teams model everything as an Entity when Value Objects are simpler and safer. If two objects with the same attributes are interchangeable, use a Value Object.
Ignoring strategic design -- Jumping straight to Aggregates and Repositories without mapping contexts leads to a distributed monolith. Strategic design is not optional.
One model to rule them all -- A "Customer" in billing is not the same as a "Customer" in shipping. Let each context own its own model of shared concepts.