Event sourcing is not a niche solution, but a powerful concept

Allard Buijze is the founder and CTO of AxonIQ. He developed his passion for programming at the age of six. In his professional career, he has helped both large and small companies to develop high-performance and scalable applications. Now he has made it his mission to simplify the implementation of large systems by applying the concepts of domain-driven design, command-query responsibility segregation (CQRS) and event-driven architecture.

iX: How did you first come across event sourcing as an architectural approach?

It was sometime in 2009, when I was still working for a consulting company where I was responsible for a number of projects. I was fed up with the fact that the complexity of the solution ended up being much higher than the complexity of the problem we were trying to solve.

I started experimenting with different concepts. Domain-driven design helped me a lot. But there had to be something else.

At this point, I saw a conference presentation by Greg Young. He suggested separating the reading side from the writing side. He also introduced the concept of representing and storing all changes to an application as events. We know these concepts today as CQRS and event sourcing.

I started experimenting with these ideas. The result of this experimentation became known as the Axon Framework.

Event sourcing and event storming – a collaborative approach to modeling a domain as a series of domain events – sound like natural complements. Can all event storming domains be implemented with event sourcing by storing and replaying the domain events?

Event sourcing is indeed a great fit for event storming. We also see that event modeling, a slightly different process, is becoming increasingly popular in the event sourcing community.

Unfortunately, it's not so easy to save events and then call it a day. With event sourcing, you have to think carefully about how to store these events because there will be a lot of them. You also need to be able to access them very efficiently. For anyone venturing into the realm of event sourcing, I highly recommend using an existing framework or tools that have been developed for this task. It will save you a lot of time and frustration. Kafka is good for many things, but event sourcing is not one of them.

But the two go hand in hand very well. If you want to build an event sourced system, you should use a technique like event storming or event modeling to explore your domain and design your system. This is because the focus here is on what happens in a system and not on the static data attributes we assign to it. Any data-oriented approach to designing a system gets in the way of implementation with event sourcing.

What is the best way to assess whether event sourcing is the right solution for a particular problem?

I always thought event sourcing was a niche solution. That it only made sense if you were really interested in recording the history of your system for auditing purposes. I was wrong.

Event sourcing is a powerful concept. It allows you to capture information today that you may need in the future. Many developers I talk to would rather focus on what's important today because they know they can build that other component later. Even though event sourcing involves a certain amount of complexity, it allows you to deal with complex systems much better than with traditional, data-oriented approaches. It also gives you a very reliable single source of truth that you can use to troubleshoot your system or explain anomalies in your data.

To quickly find out whether event sourcing is the right method, I would recommend designing the system using event modeling. If this works well and the behavior of a system can be expressed with commands, events and queries, event sourcing might be the right approach.

Event sourcing forces developers to focus on the behavior of a system rather than the state. This usually also leads to better alignment between the developers and the business stakeholders' requirements for the software. And when the gap between business and software is smaller, it becomes easier to see where changes need to be made to accommodate changes in requirements.

A word of warning for those venturing into event sourcing for the first time: don't confuse event sourcing with event streaming. Also, don't confuse the learning curve of using event sourcing for the first time with complexity. There may be tasks that you know how to solve but that seem more difficult with event sourcing. This is part of the learning curve.

Have you regularly observed inappropriate decisions in the implementation of event sourcing? If so, which ones? Do you have a hypothesis as to why these mistakes are often made?

Yes, there are a few common mistakes. By far the most serious mistake is the use of CRUD events (Create, Read, Update, and Delete). They describe the data changes and not the actual thinking in the business logic. These CRUD events are usually much less useful in the future. This means that we can't really take advantage of them if we keep them.

I suspect that these mistakes are made because we have been trained to think in relational data models. This starts at university and continues into our professional lives. Just ask someone to describe what a system does and they will usually start by naming all possible data attributes.

This is also where techniques like event storming and event modeling help. They really focus on the behavior and put the state last. It will feel awkward the first time, but it usually becomes second nature very quickly afterwards.

How would you describe the learning curve of a software engineer who wants to successfully start building event-driven systems? Are there any special technical skills or methods required? Do you have a recommendation on where to start?

From experience, the learning curve for event sourcing is not very steep. I have taught numerous junior and senior developers, architects and even business people. Senior developers have the most difficulty.

It turns out that the biggest problem is actually the learning curve. What holds most people back is moving away from the data mentality.

With the right tools and a good design methodology that takes events as a starting point, the technical aspects are really not that complex. Some so-called common solutions that we used to have in our toolbox are now obsolete. For these, we need to learn other techniques. It is also best to learn to deal with the model of eventual consistency on a larger scale.

The most important thing is to gain experience yourself. Try building a small, simplified version of something you are working on first. Watch out for the "data thinking trap" and you'll find that it's not that hard.

The interview was conducted by Lukas Zühl

Software Architecture Gathering

This year, the iSAQB Software Architecture Gathering 2024 will once again take place on site. The organizers, International Software Architecture Qualification Board (iSAQB) and iX, the magazine for professional IT, have chosen Berlin as the venue for the international conference on 12 and 13 November. There will be additional workshops before and after the conference on November 11 and 14.

The conference program offers 40 English-language presentations and four keynotes, including

• Generative AI Meets Software Architecture
• Secure Architectures for AI-Based Software
• Can We Measure Developer Productivity?
• Modern Architectural Work: From Defining to Enabling
• Make Your Security Policy Auditable
• Domain-Driven Transformation – How to Improve the Structure of Legacy Systems

Allard Buijze gives the presentation "Event Sourcing – Technical Detail or Architectural Powerhorse?" at the conference about his many years of experience in building event sourcing systems.

(rme)