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

Allard Bouize is the Founder and CTO of AxonIQ. He developed his passion for programming at the age of six. In his professional career, he has supported both large and small companies in the development of high-performance and scalable applications. Now he is on a mission to simplify the implementation of large systems by leveraging the concepts of Domain-Driven Design, Command-Query Responsibility Segregation (CQRS), and Event-Driven Architecture.

Advertisement

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

That was the time of 2009. At the time, I was working for a consulting company where I was responsible for several projects. I was fed up with the fact that the complexity of the solution was much greater 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 something else had to happen.

At this time I watched 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 in an application as events. These concepts are what we know today as CQRS and event sourcing.

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

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

Event sourcing is actually a great match for event storming. We’re also seeing event modeling, a slightly different process, becoming increasingly popular in the event sourcing community.

Unfortunately, it’s not as simple as saving events and ending them. With event sourcing you have to think carefully about how to store these events because there will be so many of them. You also need to be able to reach them very efficiently. For anyone stepping into the field of event sourcing, I highly recommend using an existing framework or tool designed for this task. This will save you a lot of time and frustration. Kafka is good for many things, but event sourcing is not one of them.

But these two go together very well. If you want to build an event source system, you should use techniques such as event storming or event modeling to explore your domain and design your system. Because the focus here is on what happens in the system, not on the static data attributes we assign to it. Any data-driven approach to designing a system gets in the way of implementing it 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. This only makes sense if you’re really interested in keeping track of your system’s history for audit purposes. I was wrong.

Event sourcing is a powerful concept. This allows you to get information today that you may need in the future. Many developers I talk to like to focus on what’s important today, because you know you can build that other component later. Even though event sourcing involves a certain level of complexity, it makes it possible to deal with complex systems better than a traditional, data-oriented approach. It also gives you a very reliable single source of truth that you can use to troubleshoot your systems or explain anomalies in your data.

To quickly determine if event sourcing is the right approach, I would recommend designing the system using event modeling. If this works well and the behavior of the system can be expressed with commands, events, and queries, then event sourcing may be the right approach.

Gemini Live now speaks Spanish

Event sourcing forces developers to focus on the behavior of the system and not its state. This usually leads to better coordination between the requirements of developers and business stakeholders for the software. And when the distance between the business and the software is shorter, it becomes easier to see where changes need to be made to accommodate changing requirements.

A little 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 with complexity when using event sourcing for the first time. There may be tasks you know how to solve, but with event sourcing they seem more difficult. This is part of the learning curve.

Have you noticed regular, inappropriate decisions in the implementation of event sourcing? If yes, which ones? Do you have any hypotheses as to why these mistakes are commonly made?

Yes, there are some common mistakes. By far the most serious error is using CRUD (Create, Read, Update and Delete) events. They describe data transformations and not actual thinking in business logic. These CRUD events are of little use in the future. This means that if we store them we cannot really take advantage of them.

I suspect that these mistakes are made because we have been trained to think in the relational data model. It starts from university and continues till professional life. Simply ask someone to explain what the system does and they will usually start by mentioning all the possible data characteristics.

Techniques like event storming and event modeling also help here. They really focus on behavior and put the bet last. This will feel uncomfortable at first, but it usually becomes second nature very quickly.

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

Experience has shown that the learning curve for event sourcing is not too steep. I have taught many junior and senior developers, architects and even business people. Senior developers face the most problems.

This shows that the biggest problem is actually the unlearning curve. What holds most people back is the shift away from a data mindset.

With the right tools and a good design methodology that takes phenomena as a starting point, the technical aspects are actually not that complicated. Some so-called common solutions that were once in our toolbox are now obsolete. For this we will have to learn other techniques. It would also be best if we learned to deal with ultimate stability models on a larger scale.

The most important thing is to gain experience yourself. Try making a smaller, simplified version of what you’re working on first. Beware of the “data thinking trap” and you will find it is not that hard.

The interview was conducted by Lucas Zuhl

(rme)