Bridging the world of Event Storming and BPMN

In a recent post, Bernd Ruecker made a nice post on a pattern to transform events to commands in MicroServices and DDD. The post discusses the differences between Choreography and Orchestration as two major styles in which various micro-services can be connected and the pros and cons of these styles. Creating business process based systems using DDD is something I've been working on quite a bit. In this post, I would like to take this one step further and also show how the worlds of BPMN and DDD have a very nice fit, even beyond than just this pattern.

To do this, I'm going to make a connection between BPMN and a prominent style of analysis in the DDD world - Event Storming by Alberto Brandolini. Also, I'd like to dive into how the strategic design parts of DDD can help us in guiding us where we would like to apply these patterns. The latter will be subject of a later post.

Event Storming

First things first, lets look at Event Storming and how it is used in DDD. This is not intended as a complete course on Event Storming of course. There is ample material available for that already, and I don't want to put Alberto out of business 😉 in the masterclasses he does on Event Storming (which btw is highly recommended). 

Event Storming revolves around a concept which was actually added to the methodology of DDD later on: Domain Events. Domain events are things which have happened and are important to the domain. The emphasis is to indicate the most important properties of Domain Events. The are always in the past, and matter to you.

Event Storming is a kind of workshop approach where you start of with an high-level view of the business proces expressed in the various things which have happened. Event storming starts by defining the last event which matters and then works its way backwards to the start of the process.

This approach has two important features which really help if you have a system where you're using DDD and business processes:

• It helps in defining the intent of the business proces, its start and its ending (see why that matters at this blogpost)
• It helps you to stay away from a tendency I see in various organisations where people mainly focus on the data the system processes, instead of what it does (more on that in a later post).

After doing the initial high-level Event Storming, you'll often end up with an insane amount of post-it notes, all orange of course as that's the color coding Alberto uses to indicate Domain Events. Don't be surprised if you need a few hundred of those for any decent sized process.

The next step is then to move on the a more detailed analysis, which is where you bridge into the world of DDD (high-level Event Storming can thus be used without DDD). Given that the high-level Event storming is quite large, you'll often end up selecting a specific subset of domain events and do a detailed analysis there.

How to bridge these worlds?

Let's build our first bridge: connecting Event Storming to the Event-Command Transformation pattern (I'll be using EC-XForm as a shorthand from now on). In low-level event storming you start by taking the events from the high-level event storm and taking an interesting subset of them. This is mostly driven by business value: what is the first step that you want to start working on?

From this first set of domain events, we start to create a more detailed design. At this stage, you're already starting to be in the grey zone between the business world and the IT world.

A detailed design adds to the quite simple to understand view of all domain events quite a few new concepts:

• Aggregates: These are the objects in our system, same meaning as DDD teaches us. They do stuff and out comes an Event.
• Commands: Commands is whats being told to an Aggregate to perform, the actual modification. It's why an Event is emitted.
• External Systems: In some cases Events originate from external systems. In these cases there may be aggregates and commands underlying these systems, we just don't see them.
• Actors: That's us, mostly, humans, flesh and bones and some grey matter on top to help the system in case it doesn't know what to do anymore. We make decisions and change stuff by firing off Commands.
• Read Models: Information shown to the Actor to base a decision on.
• UIs: The UI used by the Actors, so they can actually change stuff. Most people are not that comfortable to use cURL to do POST requests to our REST endpoints.
• Policys: Automated steps which translate Events originating from one Aggregate based on a Command to another Command (which again results in Events). These things contain our more high-level business rules.

By reading this, I hope you already get the feeling that these concepts are connected in some way and that there is a kind of natural flow to them. Actually there is, as can be seen in the picture below.

In this setup, you don't always have a beginning and end, things can be cut off at any point, where stuff stops being interesting. I.e. it may be that commands are sent to an external system, yet we are not interested in the events it's emitting.

Once you have a detailed event storming, you can translate that either to an Orchestration setup or a Choreography setup. In the former you translate each command to a process step (or combine them if needed). Essentially, the set of policies combined form your business process, they define at each step how the process should take action. In the latter case, the Choreography is quite clear from alle the events you need to respond to. 

Then, it's also quite clear where we can apply the EC-Xform pattern. The policy, our automated set of business rules is actually the manifestation of the EC-XForm pattern at a more analysis level. It takes events as input and transforms these in some way to commands. This is especially true if the thing the command will be invoked upon is an external system. So the pattern you want to search for in your event storming is a lilac-blue-pink set of post-it notes.

If the policy is translating an event to a command on a aggregate, this is often more a manifestation of a process step as indicated earlier. The events are often in this case not directly visible and we have a more structured view in the process. Sometimes they are expressed in the process, by means of e.g. an Message Receive event, indicating the start of the process. Often these are also the parts of your system where you follow a Choreography setup to start e.g. a process in case events arise.

Concluding

DDD and EventStorming, combined with the power of BPMN and business proces modelling combine easily into a powerful way to develop complex systems. I hope to be able to show where 

the concepts in both worlds actually have a one-to-one translation. In the next instalment of this post I'd like to dive into the world of bounded contexts and how these also provide a nice indication where we can take the results of our analysis and translate it to the application of patterns which make our systems better maintainable.