Software design approach centering development on the business domain, using a ubiquitous language shared between developers and domain experts.
Domain-Driven Design (DDD) is a software design approach that prioritizes modeling the business domain. The premise: real complexity is in the domain, not in technology. DDD provides patterns to handle that complexity.
DDD bounded contexts naturally map to microservices. Each microservice implements a bounded context with its own model and data.
| Situation | DDD? | Alternative |
|---|---|---|
| Complex domain with rich business rules | Yes — DDD shines here | — |
| Simple CRUD without business logic | No | Traditional layered architecture |
| Team without access to domain experts | Partial — tactical patterns without strategic | — |
| Startup in exploration phase | No — too much ceremony | Simple modules, refactor later |
| Legacy system being migrated | Yes — bounded contexts guide decomposition | Strangler fig |
DDD provides a language for aligning code with the business domain. In complex systems, bounded contexts define clear boundaries between teams and services, avoiding the coupling that turns monoliths into systems impossible to modify.
Architectural style structuring an application as a collection of small, independent, deployable services, each with its own business logic and data.
Principles and practices for designing clear, consistent, and evolvable programming interfaces that facilitate integration between systems.
Pattern separating read and write operations into distinct models, optimizing each independently for performance and scalability.
Architectural pattern isolating business logic from the outside world through ports and adapters, facilitating testing and technology changes.