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.
After defining events of the Payment aggregate it’s time to move on and work on applying these events.
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 underst anding of our approach
Interested in learning more about topics like this? Click here to join my newsletter. No spam. Meaningful content only.
All events are applied with an Apply method.
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.
And UserId property is missing the typeby t.pluskiewicz at 2017-01-19 11:27:47 +0000
Are you not using highlighted code blocks? :)by t.pluskiewicz at 2017-01-19 11:28:07 +0000
Nope. I had some problems with various RSS readers. Will reevaluate.by Szymon Kulec 'Scooletz' at 2017-01-20 12:17:10 +0000
It should be double equal: if (response.Status = GatewayResponseStatuse.OK)by Vladimir Gaevoy at 2017-01-19 09:56:20 +0000
[…] the last entry we changed the Payment aggregate to modify state by raising events. The events weren’t […]by Event sourcing: making it functional (6) | Szymon Kulec `Scooletz` at 2017-01-23 07:56:33 +0000