What is EventStorming?

EventStorming is an approach created by Alberto Brandolini to help you model your business domain as a team. It may sound pretty basic, but it’s really effective!

Do you remember the last time you sat down with developers and business experts to discuss a new feature, improvements or even confirm an existing way of working?

For various reasons, there may be a lack of understanding of the business or a vision that differs from one person to another.

That’s where EventStorming comes in! It will enable you to model your business domain by having a real exchange between business experts, developers and stakeholders so that everyone has the same understanding of the business. (Ubiquitous Language – DDD).

Before getting started

The environment and people

The environment is important for the EventStorming to run smoothly. Ideally, a room with plenty of wall space (without feeling restricted) would be perfect!

The people present (8-10 max) can be development team members, business experts or stakeholders. For obvious reasons, the presence of business experts is highly recommended.

There will also be the role of the facilitator, who will ensure that the workshop runs smoothly and without taking a position on what is being discussed.

Of course, for this to be effective, the environment must be conducive to discussion so everyone can exchange ideas without fear in a friendly atmosphere.

The material

The workshop doesn’t require much in the way of materials: Post-it notes of different sizes and colours and a felt-tip pen per person will suffice.

As accessories, a large roll of drawing paper (several metres long) that can be taped to the wall can also be an asset. In this case, the Post-it notes can be stuck to it, and the whole roll kept, if necessary, the possibility of adding annotations in felt-tip pen.

The duration

In theory, the workshop shouldn’t last more than two hours. But having done it several times, I find it difficult to stick to, especially during your discovery phase.

I’d also advise you to have a “Time Keeper“, probably the facilitator, who will tell you when to take a break or stop the workshop.

You may not be able to finish your workshop in a single sitting. I haven’t seen any specific recommendations on this subject, but I’d like to say that if you want to organise another session to continue/finish, go ahead!

Domain Events: here we go!

The workshop begins with what is known as domain events, represented by orange Post-it notes (the facilitator must ensure that the legend is clearly visible to everyone).

These are key events in your business that have already taken place and cannot be changed. They are represented by a sentence/verb in the past tense and are placed in chronological order, if possible (following a timeline) on the wall or roll of paper:

If we take an e-commerce site as an example, when you add an item to your basket, you might think that there is a business event, such as “Item added“:

And so the workshop begins, with everyone trying to identify the domain events in relation to the business context being dealt with and sticking them up (for a few minutes). Don’t hesitate to take advantage of all the space at your disposal!

It can be difficult to start the workshop, but participants should try to get out of their comfort zone and collaborate.

Tip: while the room is being prepared, the facilitator can remove or move away any chairs present so that everyone can get into the action more easily by standing up!

Once the Post-it notes have been stuck, everyone can exchange ideas to remove identical events so that only one remains (Highlander method?) and ask for clarifications.

The Commands

The commands follow once the workshop has been launched with the domain events.

A command represents an action written on a blue Post-it note, suggesting the intention with an imperative verb.

If we take the previous example of e-commerce, a command could be “Add item“. It often triggers a domain event and is placed just before it:

Note that one command could trigger several domain events if necessary.

The Actors

An “Actor” is a person who initiates an action (often a command). They are noted on yellow Post-it notes with a small drawing of a person.

This workshop aims to highlight the profession and its terms, and very often, this starts with actors who may have very specific names/roles.

I’m going to put our e-commerce in brackets to change the context completely and give you a few examples:

• The person at the entrance to a gambling casino with skills in recognising customers is called a Physiognomist;
• The person checking your train ticket is called a Ticket Inspector;
• A person who is not yet a customer but who could be is called a Prospect.

If we go back to our example, the Customer appears to be the actor who initiated the “Add Item” command. We will therefore position our new post-it note on the command that he is executing:

The workshop is an appropriate place to discuss the various players involved and their roles, which can be quite specific.

The Policies

What do you do when a command has to be executed following a domain event but only under certain conditions? Well, that’s where Policies come in.

A Policy can be a treatment or a business rule and is noted on a pink Post-it note.

There are two types of Policy:

• System: Most commonly, those which will be reflected in your system and whose origin is a business event.
• Human: Sometimes, the business is simple and more related to a human routine. In this case, the policy will not be reflected in the system, and you can paste the actor that triggers the policy.

Try to determine which policies are relevant to your context; everyone in the workshop should be able to find one or more.

As with the previous steps, once the post-it notes have been stuck down, discuss them and remove any duplicates before moving on to the next step: the External Systems!

The External Systems

It is possible that you will need various external systems for your product to work properly; these will be noted on large fuchsia-coloured Post-it notes.

External systems generally listen for domain events (Middleware Oriented Message – Messaging is often used in these scenarios) in order to trigger a command and carry out specific processing.

To give you an example, we want to send an email to the customer when the command is placed.

This email could be sent via an external system, such as Mailchimp.

“Mailchimp“, which would listen for the ” Order placed ” business event and then send an email to the customer:

External systems can eventually trigger domain events themselves, if necessary.

Do you use or plan to use external systems?

The Reads Model

Before I talk to you about the reads model, I’d like to take a quick look at the main principle behind a CQRS (Command Query Responsibility Segregation) architecture.

Behind this rather barbaric acronym lies a simple principle: separating reading (Query) from writing (Command). There is a real desire to separate the components that enable data to be queried from those that will modify it.

Sound familiar? The commands we’ve been talking about since the beginning of the workshop are perfectly aligned with this definition, and the same goes for queries, which are represented by the reads Model.

To clarify the notion of the read model, we could say that it’s the (read) information needed to make a decision. This often goes hand in hand with the User Interface (UI ), which enables an actor to make a choice before triggering a command.

They are, therefore, often linked to the user interface and will be written on green Post-it notes with the information to be used/displayed.

To continue with our e-commerce, before customers can add an item, they will first need to select the item to be added from a list of items:

The Aggregates

The idea behind an aggregate is that any entity/value object (see DDD) it contains can only be manipulated by a single object, also known as the aggregate root.

They can be more or less easy to identify, and their names are often found in similar commands and domain events.

The aggregates will be noted on long yellow Post-it notes (larger than those used for the actors) and can be placed above what appears to be an identified functionality.

In our e-commerce example, we can use the following aggregate “Order“:

You will likely identify the same aggregate several times – this is normal! In this case, for practical reasons of legibility, you can use several Post-it notes with the same aggregate name written on them.

Tip: Be careful not to have too large an aggregate (super aggregate) that manages your entire business domain.

If you ever identify aggregates with too many responsibilities, there’s a good chance that you’ll need to discuss them as a team in order to increase granularity and find new, smaller, more appropriate aggregates.

The Bounded-Contexts

The bounded context strategic pattern comes directly from Domain-Driven Design (DDD). In practical terms, a bounded context represents a logical boundary between different sets of functionalities in your business domain.

We won’t be able to display them with Post-it notes this time, but you can start by grouping closely related Post-it notes. This should make it easier to display bounded contexts.

Tip: A felt-tip pen or coloured tape can also help you to define the boundaries of the different bounded contexts.

In concrete terms, in our e-commerce, if we went further, we could project ourselves with these bounded contexts:

• Sales: this bounded context deals with items, Commands and anything related to general sales.
• Billing: this context would manage payment for the command (credit card, Paypal, etc.).
• Shipping: a context for managing command delivery (postal address, tracking, etc.)
• Notification: bounded context used to manage the sending of notifications, such as emails.

Diagram largely inspired by www.tripled.io

At this stage of the workshop, there are probably a number of distinct bounded contexts. Have you been able to identify them?

To find out more

Other triggers

To my knowledge, there are other types of triggers, such as time, with or without recurrence. In this case, you can note them on the same orange post-it notes as the domain events, with the time conditions.

For example, if your system requires processing every 1st of every month:

Doubts to be clarified

The team may not always agree with certain Post-it notes, and that’s normal!

Sometimes, a lack of information or perspective prevents the team from taking a calm decision at the time.

In this case, the choice can be postponed until later in the workshop in the hope of getting the information or the breakthrough we were waiting for.

To ensure that this is not omitted and is clearly represented on the wall, the post-it notes to be clarified, which require discussion, will be turned at 45°.

Conclusion

EventStorming can really be a workshop that helps you model your business domain as a team.

Having practised it a few times, I really think it helped the team to grasp the business and improve its understanding.

You’ll be even more successful if you use Domain-Driven Design (DDD), which is really at the heart of EventStorming. If you haven’t practised DDD, I recommend reading one of the books below.

I’ve tried here to transcribe the EventStorming process I’ve taken part in. Several variants are more or less streamlined (with/without read models, bounded contexts, etc.), or some steps are not dealt with in the same order.

There aren’t really any rules; try the workshop and adjust it to suit your context and your team so that it’s both appropriate and effective! On your post-its!

Resources

• Alberto Brandolini Website: https://eventstorming.com
• Miro Website, to create boards online and in real-time:  https://miro.com
• Book Domain-Driven Design: Tackling Complexity in the Heart of Software, d’Eric Evans (the blue book).
• Book Implementing Domain-Driven Design, de Vaughn Vernon (the red book).