Event Storming

In a recent article: Why events matters, I tried to explain why event driven architecture makes sense to me. Not only for performance, not only for logging, not even for the shiny buzzwords, but because it is an excellent way to be aligned with your business.

This is the best implementation of Domain Driven Design (DDD) I experienced so far.

In this article, I would like to describe a method to have an “event driven mindset” since the very start of your project. This method is called Event Storming, and was formalized by Alberto Brandolini.

The idea is simple: put all the main actors of a software project in a room, provide them with (very) big walls, (lots of) stickies, enough markers for everyone and optionally some coffee. We want lots of everything, because we don’t want to constrain the mental process.
Let the collective intelligence works and… Voilà! You have a perfect software design.

Of course I am kidding, but I believe that geniuses are people able to find really useful usage in very simple concepts. Alberto understood that an event is both a technical and a business concept. And this is the whole trick, when speaking and thinking in terms of events, both technical and business people understand each other very well.

Also it is interesting to understand the relation with the London school .
In the excellent GOOS, we can read “Thinking of a system in terms of its dynamic, communication structure is a significant mental shift”. And they explain why they prefer design a system around object interaction instead of states.
Sandro Mancuso also talks about “Interaction Driven Design”, explaining how your code is in a better DDD style when you design your software around interaction.

I believe they all understood, the power of events as a business tool in their context. They understood that it is better to model a business in terms of interaction, than it terms of states.

Now let’s be concrete, how do you perform an Event Storming Workshop?

You have a subject (either a user story or even a whole new software to build), you have people involved in the subject (usually domain experts and developers), index cards and big walls.

For example, let’s say we want to build a smartphone application for a bank. The application should help the bank’s customers to follow their account state. The first step is to find all the interesting events in this context. For our example it could be AccountCredited and AccountDebited to start. Of course, we need to find the maximum of events, even if they seem not directly related to our context. We could imagine, UserLoggedIn, UserLoggedOut, UserAddressChanged etc…
Use a single index card color for all the events on your wall (let’s say we use orange only).

Note the past tense in the events. At this stage, you will start to see some “group of stickies” emerge. In other words, you will naturally want to group events that seem related in your business. Don’t bother too much with that right now, just try to write a maximum of events on the wall.

The next step is to find the commands associated with the events. CreditAccount, DebitAccount, LoginUser etc… A one-one matching with events is not required. Some commands may provide several events or some events can come from other events.
Again, use a single index card color for all the commands on your wall (let’s say we use blue only).

After that, you want to seek a logic behind the “group of stickies” that had emerge. The unit behind this logic is an aggregate (but use your own word if you like).

To explain an aggregate I will quote Florent Pellet, a fellow craftsman: “Like planets in a system will aggregate around a star, your events and commands will aggregate around a business concept.”
An aggregate is a group of events and commands satisfying a business concept. In our example we could imagine at least two aggregates: Account and User.
The interesting thing here is that an aggregate is actually  a DDD concept. And you let them emerge without even thinking about it.

Finally, with all these aggregates, with another granularity, you will naturally want to group them by business meaning (some may be used for user administration, some for sales purpose, some for customer purpose etc…). By the way it’s called bounded context (another DDD concept) but again, we don’t really care.

I won’t go too far here, but to design good bounded context, you need a very good understanding of your domain (Hey, is it DDD again?). Intuitively you will draw a line between your groups of aggregates, by thinking in terms of business responsibility.

In our example, the login responsibility is probably in a different context than the account management responsibility. In technical terms, it could be a different package, or a different project, or even a totally different software. The interesting thing is that some contexts are much more critical for your business than others. (What’s the job of a bank? Account management or user administration?)

Of course our example is oversimplistic, you will have much more than one aggregate per context! But I hope you grab the idea.

Now you have a wall full of events with associated commands, grouped in aggregates, grouped in contexts. This is an event driven domain model, as it represents your business with the possible interactions (through events and command) between different parts of your domain. It is a way to think in terms of interaction during the design.

With that you can share a conceptual representation of your software with the business, and this is by itself really valuable, even if you have not planed to design an Event Driven system!

Want to practice an Event Storming Workshop? Please invite us for a Brown Bag Lunch, or join a coding dojo on the subject, or join the workshop at BdxIO

Special thanks to Alin for the feedback.