Event sourcing: making it functional (6)


In the last entry we changed the Payment aggregate to modify state by raising events. The events weren’t captured though. In this post, we’ll change the aggregate to enable recording of these changes.

All entries in this series:

Capturing events

The easiest way to capture events is to make them pass one additional method. We could provide one Apply method in the aggregate itself that beside applying the event it would. To make it usable in all the aggregates we could create a base class that would have this method. Let’s apply it to the Payment first


Now, we need the aggregate base class to hold the capture the applied events.

The base aggregate

We use the base class to track the changes and provide one point of entry to applying events. The dynamic is used to implement it fast. If you wanted to optimize, you could remove it by writing a custom dispatcher that calls directly a method from the derived aggregate.


When the action ends, a handler executing it calls GetEvents and gets all the events that were raised during this session. This enables you to write simple tests with a Given-When-Then approach and easily extract the changes for persistence purposes. On the other hand, we introduced the base class for the aggregate. What could be done more?


By introducing a base AggregateRoot class we enabled capturing all raised events. This simplified a little bit Payment aggregate itself, but introduced the base class. It’s time to move to the final part where we make it functional removing some code we’ve written so far.

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

  1. Yes, I went through the entire documentation; while I find it quite comprehensive on technical details, it lacks some of the general design guidelines. Also the “aggregation” projection concept made me initially confuse it with an aggregate root, due to naming I believe. I like the idea of calling it “state” (or maybe I misunderstood something again? 😉 )

    Anyway, I’d be very glad to see the continuation of the series based on Marten, kind of “real-world” infrastructure stub/guidelines. For instance, how to properly design the AggregateRoot base class – so that the event is appended to the stream, and also to the current aggregate’s state (projection?). Should the aggregate be injected with event dispatcher instance? Should it be responsible for loading it’s current state (projection) when instantiated? ..etc.

    I believe this would be extremely helpful, especially for beginners like me.

    Looking forward to read more on this blog 🙂

  2. I really love the series. Recently I’ve stumbled upon Marten framework and I’d really love to see some guidelines like this tutorial, in relation to Marten – how to work with the inline projections etc. Any chances?

Comments are closed.