Jump to a problem, path or page
01 · Develop the design
Compile a validated versioned transition table and evaluate one pure guarded transition per event. Repository transactions atomically record new state, idempotency outcome and effect descriptors for later dispatch.
Stage 1
Make the table unambiguous
Allow one transition per source-state/event-type pair. Optional guards can reject it but do not select competing transitions.
Stage 2
Separate calculation and publication
The reducer computes a new immutable state and effect descriptors. Persistence publishes them together.
Stage 3
Bind events to content
Store the event ID, canonical request identity and result. A duplicate after later transitions returns its original result.
02 · Work through the method
03 · Justify the choices
Where should external side effects run?
After durable effect intent is committed
A rejected or rolled-back transition must not already have emitted its external effect.
How are competing events serialized?
Using an atomic expected-version check or row lock
The repository must enforce the state transition boundary.
What happens when two definitions match one state/event?
Reject the ambiguous definition
This engine requires deterministic single-transition selection.
04 · Plan the evidence
Jump to a problem, path or page