functional-enforcing-consistency-boundarieslisted

# Enforcing Consistency Boundaries ## Overview Some rules must hold at every instant: a booking's total equals the sum of its treatments; a booking never double-books a room. Others may lag: a customer's loyalty points can catch up with their purchases a second later. Deciding which is which, and drawing a boundary around each set of rules that must hold together, is what makes a system both correct and able to scale. The unit is the **aggregate**: a cluster of data with one entry point, whose invariants hold whenever a change to it completes. One aggregate is one transaction. Between aggregates, consistency is eventual, and that is a design decision to be made explicitly rather than a compromise. ## When to use - Deciding what a single database transaction covers - Two records must stay in agreement and sometimes do not - Designing an update that touches several entities - A rule spans entities and nobody owns it - Deciding whether a type has identity or is a plain value Not for: drawing boundaries between subsystems, which is [functional-capturing-the-domain](../functional-capturing-the-domain/SKILL.md). ## Identity and equality Two different kinds of domain type, with different equality: | Kind | Equality | Example | | ------ | ------------------------------ | --------------------- | | Entity | Same identifier, whatever else | `Booking`, `Customer` | | Value | Same contents, no identifier | `Money`, `Address` | Conseque