Event Modeling | Domenic Cassisi / Personal Blog Sun, 17 Aug 2025 11:46:03 +0000 en-US hourly 1 https://wordpress.org/?v=6.8.2 /wp-content/uploads/2022/09/cropped-favicon-32x32.jpg Event Modeling | Domenic Cassisi / 32 32 What is Event Sourcing and Event Modeling? /2025/08/17/what-is-event-sourcing-and-event-modeling/ Sun, 17 Aug 2025 11:45:56 +0000 /?p=395 Event sourcing and event modeling are two concepts that are gaining more and more attention in the software engineering community. They are related, but not the same. In fact, they complement each other beautifully. While one focuses on how we store and process information, the other focuses on how we model and communicate what a system does.

What is Event Sourcing?

At its core, event sourcing is about storing the facts of what has happened in a system. We call these facts events. These events are the primary source of truth. Any state built from those events is simply an interpretation. Sometimes, you also hear the term “projection”, which is used synonymously.

Instead of storing only the current state of an object, which is common in more traditional approaches, we keep a log of everything relevant that has happened in our domain or business, like user onboarded, order placed, export requested, and so on.

Why would you be interested in keeping a log instead of the current state?

  1. You don’t lose information! You always have the full history of what has happened. Even though a particular piece of information (fact or event) might not seem relevant today, it could become important for a new feature or requirement tomorrow. Just look at how important data has become in the age of AI.
  2. You can always build and rebuild the state at any point in time. Need a new feature that presents data differently and doesn’t fit your current model? Just build another projection — another interpretation of your raw facts.
  3. Reduced coupling. If you store state, your source of truth is bound to a specific structure or model in mind. These models often need to evolve over time due to changing requirements or new features. This means that you are now coupled to this model, which can introduce more friction than necessary, as you need to somehow squeeze that new requirement into your model. On the other hand, if you rely solely on events/facts, you will end up with less coupling, as your facts will stay facts, while your interpretations of these facts can vary over time.

What is Event Modeling?

While event sourcing is more about storage, event modeling is about design and communication.

Event modeling is a visual modeling technique that helps teams describe how a system works. It’s a way to reason about the behavior of a system. The main building blocks are commands, events, views, user interactions, and automation. It lays out the flow of information through our system across time, just like a storyline, making it easier to see how the system behaves and where boundaries are.

For me, the big strength of event modeling is that it creates a shared understanding, not only for developers, but also (and especially) for business stakeholders, designers, architects, and anyone else involved in the process. At the same time, it avoids ‘technical noise’ by staying tech-agnostic. The resulting artifact of applying event modeling is an event model you can build upon. However, the event model doesn’t enforce any particular implementation.

How Do They Fit Together?

Here’s where it gets interesting: you can use your event models as blueprints for an event-sourced system.

Since event modeling focuses on events as the central concept, it naturally aligns with event sourcing. For example, the commands and events you define in your event model map directly to the commands and events in your event-sourced system.

Some practitioners, like Martin Dilger, even generate most of the code of their event-sourced systems directly from the event model.

However, event modeling does not enforce event sourcing or any other particular implementation. You can use event modeling to describe systems that are implemented with more traditional CRUD approaches. Even if you are not using event sourcing, the modeling process still helps you clarify workflows and create a shared understanding and language for your system.

Why should I care?

It is not about technical tooling or the concepts themselves. It is the mindset shift that is so valuable, in my opinion. This also includes moving away from a purely structural way of thinking toward a more process-oriented approach that often aligns better with how businesses operate.

Maybe it’s just me, but I think it’s too easy to get distracted by technical solutions or infrastructure today, while the real problem hasn’t even been understood yet. That’s why I think it’s important to take a step back and focus on the fundamentals instead.

Where to learn more?

There are many free and paid resources available; here are just a few:

]]>