An order aggregate example
This simplified teaching example illustrates aggregate behavior and event persistence. It is not a customer deployment or a complete order-processing model.
The order stream
An illustrative stream order-123 contains OrderPlaced at v1, ItemAdded at v2, PaymentAuthorized at v3, and OrderShipped at v4.
The event names must match the actual domain language. This example assumes items may be added after placement and that shipment requires payment authorization.
Building a read model
An order-list projection processes the events and stores the fields needed by the query interface, such as order identifier and status.
A separate projection may build a list of orders awaiting payment. Both read models derive from events; neither replaces the aggregate's decision logic.
Handling user changes
A client can submit the version of the order it displayed. The command handler checks that precondition and persists resulting events with the appropriate expected version.
If the read model has not yet processed a successful append, the interface should communicate that delay rather than suggesting the command failed.
Extending the model
Cancellation, refunds, and partial shipment require explicit behavior and events. Do not edit an earlier event to make the stream appear as if a completed operation never happened.
Inventory and payment may belong to other aggregates or bounded contexts. Define coordination and failure handling explicitly.
Practical exercise
Implement one valid state transition, one rejection by an invariant, and one rejected append due to a version conflict. These are different outcomes.
Event Sourcing learning path · Previous · Next · Chronacta documentation