Domain-Driven Design
Model software around the core business domain using a shared language between developers and domain experts.
★★★★★4/5System topology — how multiple services are organised
How it works
Domain-Driven Design (DDD), introduced by Eric Evans, focuses on building software that reflects the business domain deeply. Key tactical patterns include Entities, Value Objects, Aggregates, Domain Events, and Repositories.
Strategic DDD maps the domain into Bounded Contexts — autonomous subsystems with their own model and language. A Context Map defines how Bounded Contexts integrate.
The Ubiquitous Language is central: developers and business experts use the same terms, and the code reflects those terms directly.
Why it matters
As software complexity grows, a mismatch between the business model and code leads to bugs and miscommunication. DDD aligns code with business reality, making systems more maintainable as they grow.
✓ When to use
- →Complex business domains with rich behaviour
- →Long-lived products with continuous feature development
- →Large teams that benefit from explicit Bounded Context boundaries
✗ When NOT to use
- →Simple CRUD applications with no meaningful business logic
- →Short-lived projects or prototypes
- →Teams without domain expert access
Trade-offs
Code directly reflects business concepts
Significant upfront investment in domain modelling
Natural service boundaries via Bounded Contexts
Requires deep collaboration with domain experts
In production
Platform architecture modelled around DDD Bounded Contexts per domain team
Microservices decomposition guided by DDD Context Maps
Industry adoption
Related principles
Clean Architecture
LiveOrganise code into concentric dependency rings so business logic never depends on frameworks, databases, or UI.
CQRS
LiveSeparate the model used to read data (Query) from the model used to write data (Command) — each optimised independently.
Event Sourcing
LiveStore state as an immutable log of events rather than the current snapshot — rebuild state by replaying events.
Microservices Architecture
LiveDecompose an application into small, independently deployable services that communicate over a network.