An aggregate is a consistency boundary around related domain objects. It protects business invariants by applying constraints within one boundary and one transaction, preventing invalid states. section 12.3.2 section 12.7
Design the boundary around the rules that must hold together. In seat allocation, Seat, Row, and ScheduledMovieSeating can form an aggregate whose root manages changes so one seat cannot be allocated to multiple tickets. section 12.3.2 section 12.5
Use these design prompts when moving from collaborative modeling toward implementation:
- Identify the business invariants that must never be violated. section 12.3.2
- Place the related domain objects inside one consistency boundary when the invariant must be enforced atomically. section 12.3.2
- Translate discovered constraints into aggregate methods and refine them through deeper business discussion. section 12.7
Preventing duplicate seat allocation
A scheduled movie must not reserve one seat for multiple tickets. An aggregate containing Seat, Row, and ScheduledMovieSeating can enforce that rule through ScheduledMovieSeating as its aggregate root. section 12.3.2
Figure 12.14 Our EventStorm is divided into consistency boundaries (rectangles). Most of the events reside within the Seat allocations context. Two commands and events are from different bounded contexts (rounded corners): Price Calculation and Payments.
Use the consistency-boundary map to distinguish the Seat Allocations aggregate area from Price Calculation and Payments in other bounded contexts. section 12.3.2
