ChrisRight now I am reading “Domain driven design distilled” to get started with DDD.
Some notes on aggregates worth a TIL entry:
An entity is an individual thing inside the bounded context. It is unique and has an identity to distinguish itself from other entities.
An aggregate is composed of one or more Entities, where on Entity is called the Aggregate Root.
Aggregates may also have Value objects associated to them.
A Value object represents a Value, differently from Entities they don’t have a unique identity.
A value object is useful to put a measure and describe a property of an entity.
An Aggregate is defined as a “transactional consistency boundary”.
Makes sure that all business rules are consistent and e.g. transactionally committed to the DB, business rules and invariants are respected, validations are coherent etc.
An Aggregate ensures consistency within the domain after an operation.
Rules of thumb:
- Respect Business invariants inside the boundaries
- Design small aggregates (following SRP)
- References through identity only
- Updates other aggregates though domain events with eventual consistency
Avoid the Anemic Domain Model (OOO design, where aggregates have only public accessor but no business logic).
Model you domain using an Ubiquitous Language.