Event sourcing: making it functional (4)
This post has been imported from my previous blog. I did my best to parse XML properly, but it might have some errors.
If you find one, send a Pull Request.
TL;DR
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
Events
The first and the most important event, is the fact of iss uing 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.
Summary
We discovered three meaningful events:
- PaymentIssued
- PaymentProcessedSuccessfully
- PaymentProcessedWithFailure
In the next entry we will start rewriting the aggregate to use these.
Comments
Why post images instead of text?
by krepiarz at 2017-01-16 09:02:17 +0000Some feed readers had problems with displaying snippets correctly. I might reconsider going back to text snippets though.
by Szymon Kulec 'Scooletz' at 2017-01-16 10:02:22 +0000
[…] defining events of the Payment aggregate it’s time to move on and work on applying these […]
by Event sourcing: making it functional (5) | Szymon Kulec `Scooletz` at 2017-01-19 07:56:46 +0000
