I propose that events composing a well-designed event model should be of a form:
Where:
- EAix→y is the event communicating transition of aggregate/entity Ai from business state Sx to business state Sy
- Ai is the i-th instance of aggregate or entity A consisting of attributes {α, β... ω}
- State transition (Sx → Sy) is accompanied by changes in a subset of attributes of Ai {α, β... μ} to new values {α', β'... μ'}, these new values (if required, with previous values {α, β... μ}) are included in the data payload of the event EAix→y{α', β'... μ'}
This approach is in contrast with a trivial event model where events are simply attribute-level changes, e.g. instead of emitting EAix→y{α', β'... μ'}, emit the following series:
Ergo, developing a business state-centric event model requires starting with business state transition diagram for entity/aggregate A:
The benefit of business state-centric event model is to make explicit the state transitions (which typically involve changes to more than one attribute), instead of those having to be inferred/reconstructed by the consumer of attribute level events EαAi {α'} = Ai {α'}.
