Before you dive into this topic - there is a new Online Course āImplementing Eventsourcingā, that will guide you step by step through this process. Find more details at the end of this article.
Important topic today - how do you model Branches in Event Modeling?
First of all, what we do with Event Modeling is simple - we visualize information flow.
Most of the time, information doesnāt just flow from left to right, but follows some Business Rules.
This is where most people start to think about loops, conditions and branches in the flow.
If this rule applies, then this flow should happen, in all other cases this other flow should happen.
āHow do I model this?ā
In general, this isnāt wrong but stands in contrast to one of the most important rules in Event Modeling:
have one linear flow from left to right. No exceptions.
How do we overcome this problem?
Describe business rules using Given / When / Then
This is where āGiven / When / Thensā start to play a crucial role. The āGiven / When / Thensā describe all the different possible outcomes of a process step.
In Event Modeling we simply agree to follow one path at a time.
Letās have a quick look at a simple rule. You should be able to immediately tell the underlying business rule from just looking at the āGiven / When / Thenā presented here:
In this case, we model the rule as an error flow.
āGIVEN we already have a timesheet for an email-address and a period, WHEN someone tries to generate another timesheet for the same E-Mail and the same period, THEN the system should transition to an error stateā
Quite readable and easily translated to a running specification.
At the same time, we could also model it differently.
When do we model it as an error and when do we store an Event? This depends on the use case - do we have a follow up process that needs the information that the timesheet creation failed at some point in time? Do we need this information for reporting or auditing purposes? That might be a good reason to store an Event. If itās just a validation error and the user simply retries as many times as necessary, it might be fine to go with a simple Exception.
We have one business action āCreate Timesheetā, but two different possible outcomes. For this flow we āchooseā to follow the good case of āTimesheet Createdā. But how do we model the ābad caseā of failure. Is it another model? Is it another flow?
Typically itās just another part of the flow that comes later. We call this a chapter (indicated by the blue arrow). For me, the starting point is crucial. The āTimesheet creation failureā chapter starts with a linked Event - the āTimesheet creation failedā Event. The arrow in the corner of the Event indicates that the Event is not created here, but somewhere else and we just start the flow here.
Clicking on the arrow brings you back to the original Event (in the last picture)
Basically that is the conditional flow - just modelled in a linear way so itās easily readable.
This is how you overcome the āconditional branching problemā in Event Modeling. Linearize it!
Hope that helped!
Do you want to evaluate Event Modeling for your Team? Get an expert and save time.
I offer a Event Modeling Trainings for Teams - and weāll work on one of your business problems for one full day.
Want to practice your skills in a safe environment?
The Online Course āImplementing Eventsourcingā gives you exactly that. Itās a perfect companion to the Book āUnderstanding Eventsourcingā!
Everything I know about Evenet Modeling & Event Sourcing in one practical course course.
Martin Dilger
Join the Agentic Engineer Program
Apply Spec-Driven Development Hands-On - Event Modeling, Event Sourcing, and AI Engineering with autonomous agents.
Book a Call Today
Want to talk through how Event Modeling could work for your team or project? Letās have a quick, no-pressure conversation.