Domain Model
Wow uses an aggregate as a consistency boundary: the command side decides from current state, the state side evolves only through domain events, event streams in EventStore preserve authoritative history, and snapshots only accelerate latest-state restoration.
This section covers domain boundaries, state evolution, historical compatibility, and restoration cost. Complete Gateway, Dispatcher, Filter, and wait-stage behavior belongs to the Command Processing Pipeline, not to the domain model.
The capability map below shows how the domain-model pages grow from the aggregate boundary.
Choose a Reading Path
First Modeling
- Read Aggregate and Invariants to define aggregate identity, business invariants, and allowed state transitions.
- Read Event Sourcing to establish that event streams are authoritative history and state evolution is deterministic.
- Read Aggregate Lifecycle to confirm creation, restoration, deletion, and concurrency boundaries.
Completion signal: Every business intent has an explicit success event or rejection result, and the same initial state plus event order produces the same state.
Primary next step: Define Commands to map each business intent to its target aggregate and handling function.
Historical Evolution
- Start with Event Sourcing to confirm current streams, revision distribution, and restoration boundaries.
- Use Event Evolution to design single-step upgraders, chain order, and field compatibility.
- Use Aggregate Lifecycle to verify versions, metadata, and business state after replaying old events.
Completion signal: Every historical revision that still exists upgrades and replays into current state, with critical business invariants and downstream outcomes verified.
Primary next step: Run a full replay with sanitized real-history samples and keep a repeatable verification entry point.
Restoration Performance
- Use Event Sourcing to measure the number and duration of events replayed for latest-state restoration.
- Read Snapshots and select a strategy and store only when performance evidence exists.
- Use Aggregate Lifecycle to ensure latest restoration and point-in-time restoration do not mix snapshot rules.
Completion signal: The selected strategy meets a measurable restoration target, and missing or stale snapshots can still be rebuilt from authoritative event history.
Primary next step: Benchmark restoration against realistic aggregate histories and verify the selected SnapshotStore's monotonic-save contract.
Page Responsibilities
| Page | Question answered |
|---|---|
| Aggregate and Invariants | How are consistency boundaries, identity, and business rules modeled? |
| Event Sourcing | Which history is authoritative, and how is state restored deterministically? |
| Snapshots | When should a replaceable checkpoint optimize latest-state restoration? |
| Event Evolution | How can persisted event-schema changes remain compatible with old history? |
| Aggregate Lifecycle | How is a StateAggregate created, restored, and evolved in order? |