Menu
In anticipation of Allard Buijze's session "Event Sourcing – Technical Detail or Architectural Powerhorse?", Lukas Zühl and Richard Wallintin (both WPS – Workplace Solutions) asked him some relevant questions.
How did you first encounter Event Sourcing as an architectural approach?
This was sometime in 2009. I was still working for a consultancy firm, where I was responsible for a number of projects. I got fed up with the fact that the complexity of the solution ended up being much higher than the complexity of the problem that we were solving with it.
I started to experiment with different concepts. Domain Driven Design (of which I attended a training with Eric Evans in 2008) helped to a large degree. But there had to be something else.
This is when I saw a conference presentation by Greg Young. He suggested to separate the "read side" from the "write side". He also presented this interesting concept when all changes to an application could be represented and stored as events. We now know these concepts as CQRS and Event Sourcing.
I started to experiment with those ideas. The result of that experiment got known as Axon Framework.
Event Sourcing and Event Storming – a collaborative modelling approach where we model a domain as a series of domain events – sound like a natural fit. Can/should all event stormed domains be implemented using event sourcing by „simply“ storing and replaying these domain events?
Event Sourcing is indeed a great fit with Event Storming. We also see Event Modeling, which is a slightly different process, picking up in popularity in the Event Sourcing community.
Unfortunately, it's not as simple as just storing those events and calling it a day. Event Sourcing requires quite a bit of thought around how to store these events. That's because there will eventually be lot of them. You also want to be able to access them very efficiently. Anyone venturing in the realm of Event Sourcing, I strongly recommend using an existing framework or tools built for the job. It will save you a lot of time (and frustration). And mind you, Kafka is good at a lot of things, but Event Sourcing is not one of them.
But the two do go very well hand-in-hand. If you would like to build an Event Sourced system, you are far better off using a technique like Event Storming/Modeling to discover your domain and design your system. That is because it puts the focus on "the things that happen" in a system, rather than the static data attributes we assign to it. Any "data-oriented" approach to designing a system will get in the way of implementing it using event sourcing.
How can we best evaluate whether Event Sourcing is the right solution for a particular problem?
I used to think that Event Sourcing was a niche-solution. That it was only useful if you really cared about keeping the history of your system for auditing purposes. I was wrong.
Event Sourcing is a powerful concept. It allows you to capture information today, which you may need in the future. Many developers I talk to love the fact that it allows you to focus on what's important today, knowing that you can build that other component later on. Although Event Sourcing comes with a little bit of complexity of its own, it allows you to deal with complex systems in a much better way than the more traditional, data-oriented, approaches. It also gives you a very reliable source of truth, which you can use to debug your system or explain any anomalies in your data.
To quickly test the waters and find out if Event Sourcing would be a solution, I would recommend trying to design the system using Event Modeling. If that works nicely, and the behavior of a system can be expressed using Commands, Events, and Queries, then Event Sourcing could be a great fit.
One thing Event Sourcing forces developers to do, is focus on the behavior of a system, rather than the state. This generally also results in a much better alignment of how developers build the software with what the business stakeholders want it to do. And when the distance between Business and software is smaller, it becomes easier to find where changes need to be made to accomodate for changes in requirements.
A little warning for those who venture into Event Sourcing for the first time: don't confuse Event Sourcing with Event Streaming. Also, don't confuse the learning curve of applying Event Sourcing for the first time with Complexity. There may be tasks that you know how to solve that seem more difficult with Event Sourcing. That's part of the learning curve. There is also a lot of content available to help you solve those tasks.
Have you seen certain inappropriate implementation decisions for event sourcing repeatedly? If yes, which? Do you have a hypothesis why these mistakes are made often?
Yes, there are a few common mistakes. By far the biggest mistake, and also the most detrimental one is "CRUD events". This is where events describe changes in data, rather than the actual "think" that happens in business terms. These "CRUD events" tend to be much less useful in the future. This means that we're doing an effort to keep them, but we can't really reap the benefits.
My hypothesis on why these mistakes are made is because we've been trained to think in terms of relational data models. This starts in University, and goes on in people's jobs. Just ask someone to describe to you what a system does, and they generally start by naming all sorts of data attributes.
This is also where techniques like Event Storming and Event Modeling help. They really put focus on behavior, putting state in the very last place. It will feel awkward the first time, but it tends to feel natural very quickly after.
For a software engineer to start building event-sourced systems (successfully), how would you describe the learning curve? Are unique technical skills or methods required? Do you have a recommendation where to start?
Strange enough, my experience is that the learning curve of Event Sourcing is not very steep. I've taught numerous junior developers, senior developers, architects and even business people. The ones that have most difficulty are the senior developers.
Turns out, the biggest problem is actually the un-learning curve. Getting rid of the data-mindset is what holds most people back.
With proper tools, and a good design method that takes Events as a starting point, the technical aspects are really not that complex. A few "common solutons" that we used to have in our toolbox have become obsolete. We'll need to learn different techniques for those. We're also best off learning to deal with eventual consistency to a larger extent.
At AxonIQ, we're hosting AxonIQ Academy with trainings around several aspects around Event Sourcing. Some of these are completely free. We also regularly host (online) workshops that guide you through the process of designing, and then building an Event Sourced system.
But more important than watching videos is gaining actual experience with it. Try to build a small, simplified version of something that you're working on first. Mind that "data-thinking" trap and you'll find out it's really not that hard.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
