What rule does the attempt to violate the set of P-7 on 0 To bet, and who refuses?

The rule of a lot larger 0 per position. The root order B-1042 rejects the change, the order remains with 49,90 EUR.

To order a new position with quantity 1 added (cup), 24,95 EUR. What checks the root, and how does the sum change?

The root checks that the amount is larger 0 and remains at least one position. Then it recalculates the sum: 49,90 EUR plus 24,95 EUR is given 74,85 EUR.

Should the reservation in the aggregate order, so that stock and order are correct in a transaction?

Advantage: Both agree immediately. Disadvantage: The aggregate becomes large, and changes to stock and order block each other. Recommendation: The reservation remains its own aggregate, referenced by identifier, and follows downstream.

ConceptChapter I · Domain · Building block 5 of 7

Aggregate

An aggregate bundles objects and rules that must remain consistent together when a change is made. A root controls all changes within that boundary.

By Michael Meierhoff · Meierhoff Systems

Root rootOnly access to change.
InvariantRule that must always apply.
Consistency limitWhat must remain valid together.

Context

Why this is important

Rules about several objects can only be adhered to if the access is controlled. Without a limit, an order would result without a position or with a quantity of zero. Entities and Value Objects handle the previous building block.

This building block explains transactional consistency in the domain model. For identity and business values, see Entities and Value Objects.

At a glance · Root protects the consistency boundary

Changes go only through the root; it checks the invariant for all parts inside the boundary.

Shop example · Changes at the root

Who can change what?

Order B-1042 contains positions and a delivery address. Their rules require at least one position, a positive amount per position and an order sum that matches the positions.

This is how you read the picture

Root root The box order B-1042 accepts modification attempts and checks them.
Invariant The checklist: at least one position, quantity larger 0, the sum is correct.
Consistency limit The aggregate ordering area; payment and reservation are outside.

Aggregate ordering

Order B-1042Aggregate root (target of the test)
Position P-7Cup · Quantity 2
Delivery addressValue Object

Paymentown aggregates · by identifier
Reservationown aggregates · by identifier

Accepted

at least one position: holds
Quantity greater than 0: holds
Order amount = Total of positions: holds

Positions: P-7 · Quantity 3
Order amount: 74,85 EUR

The root checks all three rules, accepts the change and recalculates the sum: 3 times 24,95 EUR shall be: 74,85 EUR.

Prices illustrative

Choose a change attempt; the checklist shows which rule holds (prices illustrative).

Benefits & limitations

Helps if:

Several values must meet a business rule together.
Changes need controlled access so concurrent writes preserve valid states.

Boundaries

An oversized aggregate causes contention and long transactions. Determine which rules must hold together and assign suitable Transaction Boundaries.
Eventual consistency has a cost: an order may be confirmed before its reservation completes. Reservation failure then needs handling, for example through a Saga. See Consistency for more detail.

In practice

Formulate invariants first. Write down which rules must apply after each change; this consistency requirement then determines the object structure.
Choose the root and boundary. Determine which object controls changes and which data must be stored together to preserve the invariants. Align this with the relevant Transaction Boundaries.
Check concurrency and separate operations. Test simultaneous changes and decide which follow-up actions occur outside the boundary. Value Objects helps preserve valid values within the aggregate.

Read the detailed explanation

The aggregate root controls changes within a consistency boundary. It checks that a state transition is valid and preserves the associated invariants. Value Objects models immutable values within the aggregate; Transaction Boundaries helps define atomic changes.

The boundary includes only data that must remain consistent together. Other aggregates are often referenced by identity and changed in separate operations. This limits write conflicts and long transactions but requires deliberate handling of later outcomes and retries. The aggregate boundary follows the invariants that must be enforced together; business-related objects may belong to different consistency boundaries.

Vaughn Vernon's rules of thumb in 'Effective Aggregate Design' can be summarised as follows: keep aggregates small, reference other aggregates by identifier, change one aggregate per transaction and use eventual consistency between aggregates. In the shop, Payment and Reservation therefore remain separate aggregates alongside Order.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
What rule does the attempt to violate the set of P-7 on 0 To bet, and who refuses?
View the solution with justification
The rule of a lot larger 0 per position. The root order B-1042 rejects the change, the order remains with 49,90 EUR.
ApplyingTransferred to a new situation
To order a new position with quantity 1 added (cup), 24,95 EUR. What checks the root, and how does the sum change?
View the solution with justification
The root checks that the amount is larger 0 and remains at least one position. Then it recalculates the sum: 49,90 EUR plus 24,95 EUR is given 74,85 EUR.
EvaluateWeighing an alternative
Should the reservation in the aggregate order, so that stock and order are correct in a transaction?
View the solution with justification
Advantage: Both agree immediately. Disadvantage: The aggregate becomes large, and changes to stock and order block each other. Recommendation: The reservation remains its own aggregate, referenced by identifier, and follows downstream.

Explore further

These optional deepenings complement the learning goal of this page.

Repository and Factory

Tactical DDD complements aggregates with Factories and Repositories. A Factory creates an object, possibly composed of several parts, that satisfies domain rules. A Repository loads and saves aggregates by identity and hides technical persistence. Both serve the domain model and leave responsibility for invariants with the aggregate root. A Repository also does not turn several aggregates into one transaction; coordinating them requires explicit process rules.

For testingModel the creation of an order: use a Factory when customer, line items and initial status must be constructed as a valid whole, and a Repository to load and save the order. Verify that changes still pass through the aggregate root and stock reservation remains a separate operation.

References

Continue on the learning path

Next in Domain modelling: Context Map.

7 Building blocks

Continue withContext Map