Domain-Driven Design
Also known as: DDD
Evans' approach aligning software model with domain language and bounded contexts.
Domain-Driven Design was articulated by Eric Evans in Domain-Driven Design: Tackling Complexity in the Heart of Software (2003), with Vaughn Vernon's Implementing Domain-Driven Design (2013) providing more operational depth. DDD's central commitment is that complex software should be modeled around the language and concepts of the business domain rather than technical concerns, with collaboration between domain experts and developers producing a Ubiquitous Language used in code, conversation, and documentation alike. Strategic patterns address the structuring of large systems: Bounded Contexts define semantic boundaries within which a model is consistent and outside of which terms have different meanings; Context Maps describe relationships between contexts (Customer-Supplier, Conformist, Anticorruption Layer, etc.). Tactical patterns address modeling within a context: Entities (identity-bearing objects), Value Objects (no identity), Aggregates (consistency boundaries), Repositories, Domain Events, and Domain Services. DDD has been substantially influential in microservices design, with bounded contexts often serving as the natural decomposition unit.
Core components
- Ubiquitous Language
- Bounded Context
- Context Map
- Strategic patterns: Customer-Supplier, Conformist, Anticorruption Layer, Shared Kernel, Open Host Service, Published Language
- Tactical patterns: Entity, Value Object, Aggregate, Aggregate Root, Repository, Domain Event, Domain Service, Factory
- Layered architecture (interface, application, domain, infrastructure)
- Continuous refactoring toward deeper insight
- Event Storming as collaborative discovery technique
Primary use case
Complex business-software design and architecture; foundational framework for microservices decomposition (bounded contexts as service boundaries); collaborative modeling between developers and domain experts; team and code organization in large enterprise systems; integration with Event-Driven Architecture, CQRS, and Event Sourcing.
Common criticisms
- Substantial complexity overhead — DDD is overkill for simple applications and works best for genuinely complex domains
- learning curve is steep, with many practitioners adopting tactical patterns without strategic framing
- risk of cargo-culting tactical patterns (Aggregate, Repository) without the underlying domain modeling discipline
- collaboration with domain experts assumes access and engagement that many organizations don't provide
- bounded context boundaries can be drawn poorly, leading to rigid microservices organization
- DDD plus CQRS plus Event Sourcing is a powerful combination but combinatorial complexity often exceeds team capacity
- commercial training and consulting market quality varies.
Lineage
- Siblings
- Hexagonal Architecture, Event-Driven Architecture, Microservices