Some say: “Event sourcing is hard”. Some say: “You need a framework to use Event Sourcing”. Some say: …

Meh.

You aren’t gonna need it.

Almost 2 years and over 16 million domain events ago I’ve started a process of “switching the mindset”. I had no production experience with Event Sourcing (BTW it still is used only in some parts of the application, but that’s a topic for another post), I had only a limited experience with Domain Driven Design (mainly knowing the tactical patterns). During that time, a lot has changed.

Today I was asked a question:

How to ensure that domain event published by one of the aggregates is available in another aggregate?

The story is simple. The user, who is a member of some organization, is registering a new fuckup (maybe by using Slack command). The fuckup is reported by just entering its title. It is reported in the context of the organization where the user belongs. The rest is not important here but what we want to achieve is: modify a state of an organization aggregate and, at the same time, create new fuckup aggregate.

In my last post, I’ve presented a way how to test an Event Sourced application. But again (yes, again and again) some part was missing there. It is clearly visible when you look at test coverage:

The missing part, of course, is the read side.

Some time ago I’ve published a sample application showing how to build a simple event sourced application using Rails & RES. But there was a big part missing there - the tests.

My sample uses CQRS approach to handle all operations.

Sample CQRS / ES application gone wrong

In my post Building an Event Sourced application I’ve included sample code to setup denormalizers (event handlers) that will build a read model:

def event_store
  @event_store ||= RailsEventStore::Client.new.tap do |es|
    es.subscribe(Denormalizers::Router.new)
  end
end

When you publish an event on success make sure you publish on failure too

We had an issue recently with one of our internal gems used to handle all communication with a external payment gateway. We are using gems to abstract a bounded context (payments here) and to have an abstract anti-corruption layer on top of external system’s API.

Still not sure what is Event Sourcing and CQRS? Looking for a practical example? You’ve just read my previous post Why use EventSourcing and decided to give it a try? No matter why let’s dive into building an Event Sourced application in Rails using Arkency’s Rails Event store.

Event Sourcing relies on not storing current state. All of application state is first level derivative out of facts. That opens completely new ways of architecting our applications.

But why?

There is a lot of reasons to use Event Sourcing. When you browse through Greg Young’s and other articles & talks you will find most of them. Usually they mention:

• It is not a new concept, a lot of domains in real world works like that. Check out your bank statement. It’s not the current state - it is log of domain events. Or if you are not still convinced talk to your accountant ;)
• By replaying an event we could get a state of an object (or let’s use correct term here: aggregate) for any moment in time. That could greatly help us to understand our domain, why things changed and debug really nasty errors.
• There is no coupling between the representation of current state in the domain and in storage.
• Append-only model storing events is a far easier model to scale. And by having a read model we could have best of both worlds. Read side optimised for fast queries and write side highly optimised for writes (and since there is no delete here, it could really be fast writes).
• Beside the “hard” data we also store user’s intentions. The order of events stored could be used to analyse what user was really doing.
• We are avoiding impedance mismatch between object oriented and relational world.
• Audit log for free. And this time the audit log really has all the changes (remember there is no change of state if there is an event for that).