See our books for programmers (Rails, React.js, blogging, remote)

Mirosław Pragłowski


The anatomy of Domain Event

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.

continue reading →

One event to rule them all

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.

continue reading →

Testing an Event Sourced application

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.

continue reading →

Using domain events as success/failure messages

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.

continue reading →

Why use Event Sourcing

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).
continue reading →