DDD (Domain-Driven Design)

DDD (Domain-Driven Design) is an approach to building software in which the structure, vocabulary, and logic of the code mirror the business domain — the real-world problem space the system serves. Introduced by Eric Evans in his 2003 book, it rests on close collaboration between developers and domain experts and on a model that both groups understand identically.

How Domain-Driven Design works

DDD operates on two levels. Strategic design organizes the big picture: the ubiquitous language enforces the same terms in conversations, documentation, and code; a bounded context defines the boundary within which a given model is valid (a “customer” means something different to sales than to collections); and context maps describe how those boundaries relate and integrate. Tactical design supplies the building blocks inside a context: entities (objects with identity), value objects (immutable, compared by attributes), aggregates (consistency boundaries with a single root enforcing invariants), repositories, domain services, and domain events that record business facts. Crucially, business logic lives in the domain model — not in controllers or the persistence layer — so the framework and database remain replaceable infrastructure details.

Practical applications

DDD shines in systems with rich, changing rules: payments, insurance, freight, billing, and large e-commerce platforms. Teams adopt it because:

• bounded contexts translate naturally into module or microservice boundaries and team ownership — DDD is the most common blueprint for slicing a monolith;
• the ubiquitous language collapses the gap between requirements and code, reducing translation errors;
• aggregates and domain events make data consistency and audit trails explicit;
• a pure domain model is easy to unit test, pairing well with TDD since business rules run without infrastructure.

The main pitfall is cargo-cult adoption: sprinkling repositories and value objects over a CRUD app adds ceremony without insight. Practitioners recommend starting with strategic design — talk to domain experts, name the contexts, agree on the language — and reaching for the tactical patterns only where the complexity genuinely lives.