After defining events of the Payment aggregate it’s time to move on and work on applying these events.
All entries in this series:
- 1 – back to foundations
- 2 – aggregate sketch
- 3 – first implementation
- 4 – finding events
- 5 – applying events
- 6 – recording aggregate
- 7 – the fully functional end
To apply events, the state of Payment will be extracted to a separate class. This should be a familiar pattern to all event sourcing practitioners, but let me show the code for clear understanding of our approach
How to construct the state
- There are no public setters. The state has readonly properties.
- All events are applied with an Apply method.
- The only way to change the state is to apply an event.
- No Apply throws an exception. The event has already happened and the state is just an accumulator of the changes.
New Payment Aggregate
The Payment aggregate now can be transformed to use this state, by removing all the state changes and raising/applying events in these places:
We know how to extract a state from the aggregate and apply all the events. Although Payment uses events, it does not store them in any form nor allows accessing them for processing. In the current shape the Payment isn’t much different from the previous version. We extracted a few event classes and the state, but we still can’t treat events as the first class citizen. we need to move one step further and we will do it in the next blog post.