Model Behavioural Event Streams
Design new event-sourced aggregates and event streams around business intentions, decisions, and lifecycle facts. Use when defining an aggregate from scratch, choosing stream boundaries, designing commands and events, deciding what state an aggregate needs, or planning how events rebuild that state.
Discover the lifecycle
- Collect concrete scenarios from the beginning to the end of the business lifecycle.
- Name each actor intention as a command.
- Identify the rules and current facts required to decide each command.
- Name each successful outcome as a cohesive past-tense domain event.
- Capture failures as explicit decision outcomes; record them as events only when the business needs them in the lifecycle history.
Do not begin with state fields and derive changed-property events from them. Let business behaviour define the event vocabulary and derive state from those events.
Design the aggregate
- Give one aggregate responsibility for decisions that require consistent state.
- Expose intention-revealing operations rather than setters.
- Evaluate all invariants for one decision within its operation.
- Return new domain events without mutating externally visible state directly.
- Apply each event deterministically to rebuild only the state needed for future decisions.
- Use value objects for cohesive concepts and invariant-bearing values.
For example, model ChangeDeliveryAddress producing DeliveryAddressChanged with a valid DeliveryAddress, rather than separate operations and events for street, postal code, and city.
Choose the stream boundary
Keep an event in the stream when it explains the aggregate's lifecycle or changes a future business decision. Use a separate aggregate or process manager when a workflow coordinates independent consistency boundaries over time.
Keep delivery attempts, retries, integration handoffs, projection updates, and generated artifacts outside the aggregate stream unless the domain explicitly treats them as lifecycle facts.
Check the event model
Walk every scenario through command, decision, emitted event, and applied state. Check that:
- the aggregate can make each decision from its rebuilt state;
- events remain meaningful without knowledge of storage schemas;
- replay is deterministic and side-effect free;
- duplicate or invalid commands have explicit outcomes;
- cross-aggregate work is coordinated without requiring a distributed transaction.
Deliver
Provide the lifecycle scenarios, command and event vocabulary, aggregate boundary, invariants, event payloads, state-application rules, process coordination, technical reactions, and example tests.