In the last entry we defined the aggregate implementation that we’ll work on. Let’s move forward and make it an event sourced aggregate.
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
The first and the most important event, is the fact of issuing the payment itself. Let’s define it in the following way:
The event contains all the data provided to the constructor of the payment aggregate in the past.
The next one is raised and applied when the payment is processed successfully. Let’s make it a class without any members. We just want to record a notion of success.
The last but not least is the one raised in case of the error. We make the errors explicit in here as we’d like to react to payments failure. One could model it in a different way, providing one event class, but then again, just follow this take on the payment problem.
We discovered three meaningful events:
In the next entry we will start rewriting the aggregate to use these.