DDD definition
Domain-driven design (DDD) is an approach to software development that models code closely on the business domain it serves. Developers and domain experts build a shared language, split complex systems into bounded contexts with clear boundaries, and use patterns such as entities, aggregates and domain events so the software reflects how the business actually works.
What problem does domain-driven design solve?
Large business systems often fail not because of technology but because the code drifts away from how the business thinks. Developers call something an account while finance means a customer, sales means a company and support means a login. Over time, one giant model tries to serve every department and becomes impossible to change safely. DDD, introduced by Eric Evans in his 2003 book, addresses this by putting the business domain at the center of design decisions.
Core concepts of DDD
DDD has strategic concepts, which shape how a system is divided, and tactical patterns, which shape code inside each part. Teams usually get the most value from the strategic side, even if they apply only a few tactical patterns. Splitting the model correctly matters far more than any individual class pattern.
- Ubiquitous language: shared terms used by experts and code alike.
- Bounded context: a boundary within which a model and its terms are consistent.
- Context map: how bounded contexts relate and exchange data.
- Entity: an object defined by identity, such as an order.
- Value object: an immutable object defined by its values, such as money.
- Aggregate: a cluster of objects changed together under one root and its rules.
- Domain event: a record of something meaningful that happened in the domain.
How does DDD work in practice?
Teams typically start with collaborative workshops such as event storming, where developers and domain experts map business events on a wall or digital board: order placed, payment captured, parcel dispatched. Clusters of related events and the language around them reveal natural bounded contexts, such as ordering, billing and fulfillment, each of which can be owned by one team.
Inside each context, the code uses the same names the experts use. Business rules live in the domain model, not scattered across controllers and database triggers. Contexts communicate through explicit contracts, often APIs or domain events, and translation layers stop one context's model leaking into another.
DDD and microservices
Bounded contexts are one of the most reliable ways to decide where microservice boundaries should go. A service aligned with a bounded context owns its data and language and rarely needs to change in lockstep with other services. Services drawn around technical layers or individual tables, by contrast, tend to become a tightly coupled distributed monolith.
DDD does not require microservices, though. A modular monolith organized by bounded contexts gives many of the same benefits with far less operational overhead, and keeps the option of extracting services later. Teams can then split along proven boundaries once scaling or ownership needs make it worthwhile.
When is DDD worth it?
DDD pays off in complex domains with rich business rules, such as insurance, logistics, banking or healthcare scheduling, and in systems many teams will maintain for years. For simple CRUD applications, the ceremony of aggregates and repositories adds cost without much benefit. Nexzem uses DDD workshops at the start of complex platform projects to agree on boundaries and language before writing code.