Domain-driven design (DDD) is an approach to software that makes the business model the heart of the codebase. Instead of starting from tables or frameworks, you model the domain language and rules directly.
The payoff is code that business experts can read and challenge, because it uses their vocabulary: an order is an entity, a monetary amount is a value object, and an order with its line items is an aggregate.
Entities vs value objects
An entity has identity that persists through its lifetime — a customer with an ID. A value object has no identity of its own; it is defined entirely by its attributes, like a Money value of 10 USD.
- Entities: Customer, Order, Account.
- Value objects: Money, Address, DateRange, Color.
- Value objects should be immutable and compared by value.
The rule of thumb: if two things with the same data are the same thing, make it a value object.
Aggregates and boundaries
An aggregate is a cluster of domain objects treated as one unit for changes. A transaction must not span aggregate boundaries. The aggregate root — such as an Order — is the only entry point for modifying its children.
Start small
You do not need the full DDD ceremony to benefit. Adopt the tactical patterns first: a shared vocabulary, rich domain models, and explicit boundaries. Strategic design can wait until the domain is large enough to demand it.
DDD FAQ
Is DDD only for complex domains?
Mostly yes. It earns its keep when the domain rules are intricate and valuable. For simple CRUD, the ceremony outweighs the benefit.
Do I need Event Sourcing to do DDD?
No. Event sourcing and CQRS are advanced patterns often mentioned alongside DDD, but the core building blocks work perfectly with a normal relational database.
