Event Storming

I first heard about Event Storming when I read about DDD (Domain Driven Development). It caught my attention, and now it’s a valuable tool for my teams when exploring new products/business opportunities. It is a great way to align business with software.

What is Event Storming?

Event Storming is a collaborative workshop created by Alberto Brandolini in which people brainstorm and explore a specific business process. The concept is to gather people with different expertise (engineers, designers, support, sales), domain experts and map the business process using sticky notes representing various components such as domain events, commands, actors, etc. By the end of the workshop, everyone should know how the business works and define a ubiquitous language.

Why Event Storming?

There are many reasons and benefits to conducting an Event Storming workshop:

• Build a ubiquitous language: When working in a collaborative environment with people from different backgrounds, using the same terminology and language is essential to ensure everyone is referring to the same thing and avoid miscommunication.
• Collaboration: Running Event Storming workshops improves cooperation between the product and engineering teams, which usually leads to better products.
• Model the business process: Event Storming is an effective way to build a model and map the business process. Creating a model using blocks helps identify the domains and respective bounded contexts.
• Explore new business requirements: A group of people with different expertise exploring a new business is an ideal opportunity to review the requirements and find new use cases not covered initially.
• Recover domain knowledge: Over time, a business’s domain knowledge can be lost due to people leaving, outdated documentation, and business changes. Lack of knowledge is common when modernising legacy systems. Event Storming can be an excellent technique for spreading knowledge and creating a coherent picture of the business process.
• Explore ways to improve an existing business process: The Event Storming workshop is a complete end-to-end picture of the business process, which provides a perspective on noticing inefficiencies and opportunities to improve the process.
• Onboard new members: Facilitating Event Storming workshops can be ideal for ramping up new joiners and accelerating their knowledge about the business process.

How to run an Event Storming workshop?

Before running the workshop, it is essential to do some preparation:

• Share a product discovery document in advance with all the participants so they can learn and understand the business use case to explore during the workshop.
• Elect a facilitator to ensure everyone is following the workshop process and participating.
• Ensure there are markers and sticky notes with different colours for the participants to write their thoughts.
• Book a big room to accommodate all participants and a whiteboard to stick the notes on.
• Prepare a Miro or Figma board in advance if it’s a remote session. Here are some good templates:
  • https://miro.com/miroverse/event-storming
  • https://miro.com/miroverse/discover-user-journeys-event-storms-template/

After confirming all the previous requirements, we are ready to start the workshop following steps:

Step 1 - Chaotic exploration

At this step, each participant writes potential domain events in the business process on orange stickers, such as a customer ordering food. The order of the events is irrelevant at this phase. They must be written in the past tense to describe something that has happened. e.g. example, MenuOpened, OrderCreated. When people slow down writing new events, it’s time to move to the next phase.

Step 2 - Creating a Timeline

This step aims to order the events from start to finish. Ideally, it’s easier to start focusing on the happy paths where the business case is successful and later focus on the unsuccessful paths. During the ordering process, it is vital to refine the event names, remove duplicates, and add missing domain events to have a clear timeline of the business process.

Step 3 - Review Events

At this stage, the group should verify each domain event and discuss if it’s semantic well-written and in the correct order. During this process, it’s important to flag hot spots to discuss later. A hot spot can be a complex logic or part of the process where the group lacks knowledge.

Step 4 - Pivotal Events

Since all the events are in order, it is crucial to identify events that create a significant change in the context of the business process. These events are called pivotal events and must be flagged with a vertical line to represent the different transitions between contexts.

For example, in the following timeline: OrderInitialized, OrderCreated, PaymentStarted, PaymentSettled, OrderShipped, OrderDelivered. The OrderInitialized, PaymentStarted and OrderShipped are pivotal events because they represent different contexts in the business process, the creation of the order, payment and shipping.

Step 5 - Process Modelling

Now that we have a better overview of the problem, it’s time to model the business process using all components. The idea is to map the entire journey and create an end-to-end picture of the business process. To be explicit and reduce confusion. Each component represented by a sticky note has a unique colour.

• Actor: An actor is a person who executes a command through a Read Model. For example, an administrator is responsible for executing commands to approve holiday requests.
• Commands: A command is a decision by an actor in the system that triggers a domain event. They should be in the imperative form, like “Send Email” or “Approve Order”.
• Domain Events: A relevant event that occurs in the business process. They should be in the past tense, like “EmailSent” or “OrderApproved”.
• External Systems: An external system is a third-party system not part of the explored domain, for example, a payment gateway or email service. Typically a command interacts with an external system to produce a domain event. For example, a user requests an order using a third-party system and produces the domain event OrderRequested.
• Read Models: A read model is a view of data within the domain that the actor uses to decide to execute a command. For example, a read model can be a dashboard, a report or even the output of an SQL query.
• Policies: Usually, actors are responsible for executing commands. However, you can use policies that are triggered as a reaction to domain events to automate the execution of commands. For example, when the OrderApproved event is triggered, you can create a policy to execute a command to send an email.
• Hot Spots: The hot spot component represents an unclear problem, questions or lack of knowledge. The intention is to flag a problem and discuss it later.

Step 6 - Software Modelling

At this point, we have a colourful end-to-end picture of the business process. The final step is to find patterns that aggregate the same business context using the component aggregates.

Aggregates - An aggregate is a technical component when doing Software Modelling. After completing the picture of the process modelling, we use aggregates to identify a transactional unit that must be consistent (business concepts). In the timeline, aggregates receive a command and produce multiple events. For example, a user executes a command to request an order. The command invokes an action on the order aggregate composed of events related to the order concept.

Step 7 - Review the picture

After completing the steps, the group must review the business process until it makes sense. At this step, it’s crucial to define the ubiquitous language used in the business and software. Everyone must have the same understanding of the business process and use the same terminology. The concept of “order” must be the same for a designer, engineer or sales.

In conclusion, Event Storming is a powerful tool for understanding complex businesses and uncovering potential issues. Incorporating EventStorming early in the development lifecycle ensures a strong foundation and alignment between business and technology, reducing ambiguity and leading to more efficient product delivery.