Event sourcing: making it functional (4)

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:

Events

The first and the most important event, is the fact of issuing the payment itself. Let’s define it in the following way:

paymentissued

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.

paymentissued

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.

paymentissued

Summary

We discovered three meaningful events:

  1. PaymentIssued
  2. PaymentProcessedSuccessfully
  3. PaymentProcessedWithFailure

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

3 thoughts on “Event sourcing: making it functional (4)

Comments are closed.