Event Sourcing is not a messaging integration pattern

tl;dr: If you are sending messages to RabbitMQ to communicate one application to another, you are not doing Event Sourcing. You’re just doing messaging ;)

In the last two months, I’ve seen different nice talks using DDD, CQRS or Event Sourcing in the talk title. However, after watching the content, I think there are some general misunderstandings about some of the concepts. The most important one, in my honest opinion, is calling Event Sourcing to sending messaging to other applications using a broker. Event Sourcing is not about that. Let me explain a bit more.

Event Sourcing is an architectural style for building applications. You can implement a web application, a game or a database server using Event Sourcing. When implementing a Bounded Context, you can use different architectural styles:

  1. Spaghetti Architecture: I’m a Rasmus Fanboy (aka fuck phptherightway)
  2. Framework Fanboy: I’m a Fabpot Fanboy (aka coupled to my framework)
  3. Hexagonal Architecture: I’m an Alaistar Cokburn Fanboy (aka decoupled from my framework)
  4. Hexagonal Architecture with CQRS: I’m an Alaistar Cokburn and Martin Fowler Fanboy (aka decoupled with performance tunnings)
  5. Event Sourcing with CQRS: I’m a Greg Young Fanboy (aka I do not know what I’m doing)

Enough jokes! Event Sourcing is about representing the state of your Domain computing all the Domain Events that have happened in the system. There are tons of benefits: audit, tracking, go back to a specific time, debugging, performance, etc. If you choose to use Event Sourcing, you’re also forced to use CQRS.

With Event Sourcing, your Aggregates fire Domain Events. These Domain Events are appended to an Event Store. Each Domain Event are processed and generates a denormalizations for each read model (feature that needs to read information). These denormalizations can be done in the main Database, Cache system, secondary NoSQL Database, etc. As many as needed. With this approach, our applications don’t do the work when reading (lots of queries, caching, invalidation, etc.) but when writing (denormalize). When you need to fetch an Aggregate, you load all the Domain Events for that specific Aggregate and apply them to it. If you’re not doing this, you’re not doing Event Sourcing.

Apart of the architectural style you choose, you can decide to use messaging for integrating different applications. There are other alternatives: REST, SOAP, SOA, etc.

To sum up, you can implement a single web application using Event Sourcing without publishing any message to any other application. On the other way around, you can integrate two different web applications written with Spaghetti Architecture using messaging.

Hope it helps!

  • Anthony Ferrara

    > When you need to fetch an Aggregate, you load all the Domain Events for that specific Aggregate and apply them to it. If you’re not doing this, you’re not doing Event Sourcing.

    I would argue that if you’re doing this, you’re doing event sourcing poorly. The critical thing is that the aggregation is created from the event stream, not from read models. But the aggregate itself can become a read model (pre-aggregation). Therefore, what you do at runtime (when you need to fetch the aggregate) should simply be hitting a read model. The aggregate’s read-model would be updated in real-time by events as they are dispatched.

    Unless something catastrophic or exceptionally one-off happens, you shouldn’t really ever need read the event store at runtime.

  • yrashk

    Hi Carlos,

    I definitely agree with you that messaging is at best corollary to event sourcing and is *definitely* not a prerequisite.

    I would, however, note that I think it’s useful to be able to generalize the definitions of “aggregate” and “apply events to aggregate” to avoid narrowing down the computational choices. The terminology you use comes from DDD (Domain Driven Design) and carries certain implementation decisions from Greg Young’s camp.

    Throughout my work, I found that events (as data structures, not as messages, as you rightfully pointed out) are in fact the core of this methodology. That’s why it is “event sourcing” and not “domain projection”, after all. As long as you have the original events, different processing strategies can be employed — be it Young’s left fold, lazy event sourcing (https://blog.eventsourcing.com/lazy-event-sourcing-ed7e59007e17) or something else. I also wrote an article that’s somewhat tangential to these distinctions and their relationship: https://blog.eventsourcing.com/classic-event-sourcing-on-top-of-lazy-one-1f3f16e28c45