What is Domain-Driven Design (DDD) at a high level?
Quick Answer
DDD is an approach to modelling complex software around the business domain. Its core ideas: a ubiquitous language shared by devs and domain experts; bounded contexts that split a large domain into independent models; and tactical patterns — entities, value objects, aggregates (with a root that guards invariants), domain events, and repositories per aggregate.
DDD is about building the software model around the actual business domain rather than the database. The strategic side is the valuable part: agreeing a shared language with domain experts so the code uses the same terms they do, and splitting a big domain into bounded contexts that each have their own model, so “customer” in billing can be a different shape than in support. The tactical side is patterns like aggregates — a cluster of objects you load and save as a unit, with a root that enforces the rules — value objects, and domain events. The thing it pushes against is the anemic model where entities are just data bags and all the logic lives in service classes. It's for complex domains, not simple CRUD.
- Strategic DDD — bounded contexts, context maps, ubiquitous language. The big-picture value.
- Tactical DDD — aggregates, entities, value objects, domain services, repositories, domain events.
- Aggregate — a cluster of objects treated as one unit for consistency; you load and save it whole, and only the root is referenced from outside.
- Avoids the anemic domain model — entities with only getters/setters and all logic in “service” classes.
- DDD is worth it for genuinely complex domains; overkill for simple CRUD.