Domain-driven design
Domain-driven design (DDD) is a software-design approach, formalised by Eric Evans in 2003, that places the business domain at the centre of model design. Engineers and domain experts collaborate on a shared 'ubiquitous language' — every entity, action, and rule named in code matches a term the business uses. The model is then partitioned into bounded contexts: cohesive areas where one definition of each term holds.
DDD's two halves — strategic (bounded contexts, context maps, anti-corruption layers) and tactical (entities, value objects, aggregates, repositories, domain events) — are often adopted independently. The strategic half pays off most in large systems where naming collisions (a 'Customer' meaning different things to sales, support, and billing) drive integration cost. The tactical half pays off most where business rules are complex and ramify. Common anti-pattern: applying tactical DDD to a CRUD system that has no real domain complexity — the abstractions add cost without value. Pair with event storming for domain discovery; pair with hexagonal or clean architecture for tactical implementation.
Related terms
- Bounded context
A bounded context is the boundary within which a particular domain model — its terms, rules, and invariants — is consistent and authoritative.
- Event storming
Event storming is a collaborative domain-discovery workshop technique created by Alberto Brandolini around 2013.
- Hexagonal architecture
Hexagonal architecture (also called ports and adapters), introduced by Alistair Cockburn in 2005, structures an application so the core domain logic depends only on abstract 'ports' — and concrete adapters (web framework, database, message bus) plug into those ports from outside.