Event sourcing: making it functional (4)

Posted on January 16, 2017 · 1 min read · tagged with: #domain driven design #event sourcing


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:


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.



We discovered three meaningful events:

  1. PaymentIssued
  2. PaymentProcessedSuccessfully
  3. PaymentProcessedWithFailure

In the next entry we will start rewriting the aggregate to use these.


Why post images instead of text?

by krepiarz at 2017-01-16 09:02:17 +0000

Some 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