Event Storming

As you probably have already guessed, Event Storming (ES) comes in the shape of a workshop. This engaging and fun technique explores the Domain through events that occur in the system, sometimes even beyond. It shines when applied to big, complex systems with many Domains. By far, ES is celebrated as a method with the greatest exploring time/output ratio, letting you quickly distill the most significant aspects of your business and the rules behind them.

My Advice

To get the best out of this exercise, remember that the quality of the session largely depends on the selection of domain experts. Always ensure that your Client’s representative understands what a Domain is and who the real Domain Experts are. Without the right people, even the best facilitation might fall short, leading to overlooked details and later system implementation issues.

Tools & Setup

Alberto Brandolini, the man behind Event Storming, made sure that this modeling technique remains simple and accessible. For your workshop, all you really need is:

• A big wall
• Sticky notes in different colors (each color representing a specific meaning, but feel free to adapt them to your own preferred set)
• Marker pens
• or online tools like Miro or Muraly

Table below presents color-codes for stickies.

For example, Peter always brings sticky notes and pens to the workshop. He recalls one session when the company promised to provide all necessary artefacts, yet none were available - an experience that left him feeling unprofessional as he had to scavenge for supplies. Such mishaps emphasize the importance of being fully prepared.

Arrival

It was 9 AM when Peter stepped through the door of SHELF bookstore. With only three hours to spare before the store opened to bookworms, he hoped that exploring SHELF’s Domain wouldn’t take too long. Although Peter knew that no two Event Storming sessions are ever the same, he was optimistic that the session would be both insightful and fun.

Remember, the outcome depends on numerous factors, including the competence and cooperation of the domain experts. Sometimes, you may even end up with participants who aren’t true domain experts, so always confirm that the right people are present.

Meeting the Team

• “Hello there!” Peter heard a friendly voice from behind a big pile of Polish cuisine cookbooks. “Are you perhaps the software architect sent from Trinity to conduct our workshop?” a man asked politely.
• “Yes, it must be me. I’m Peter,” he replied, extending his hand. Instantly, Peter recognized Frank’s warm tone as he stepped forward and shook his hand. “I’m Frank, the owner of this business. I called you last week. It’s a pleasure to meet you, Peter. Come on, let me introduce you to the rest of our team.” Peter followed Frank to a big, sunny, and spacious room at the back of the store. Here, Katie and Marlon awaited him.
• “Hello guys, pleased to meet you. Today, I’ll be leading our Event Storming workshop. Let me explain what we’ll be doing in just a few hours,” Peter announced with enthusiasm.

Step 0 - Introduction

• “The aim of this workshop is to map out our collective understanding of your business processes,” Peter explained. “We’ve gathered Domain experts, developers, stakeholders, and product owners, all the knowledge holders. Expect some chaos at first; it’s the natural starting point.”
• He continued, “There are two main types of Event Storming. First, we have the Big Picture Event Storming, used to discover the business domain and share understanding. This helps us define the boundaries - whether we explore the entire business or just a segment. For SHELF, we’re starting with the whole business since no system is in place yet.”
• “What’s the second type?” Marlon asked.
• “Great question,” Peter replied with a smile. “The second is Software Design Event Storming - focused on developers, product owners, and designers. It’s more technical and might bore the business side a bit, but don’t worry - everyone’s welcome!”

Step 1 - Storming Events

Peter distributed a stack of orange sticky notes and markers. “Now, write down as many events as possible - remember, these should be in the past tense with imperative verbs. Make them sound decisive!” he urged.

In no time, the wall filled with orange squares covered in event names. “Don’t worry about duplicates; we’ll sort that out shortly,” he reassured the team.

After an enthusiastic brainstorming session, the wall looked like a vibrant mosaic of post-its. With many participants, duplicates were inevitable. Peter quickly organized the notes, eliminating the repeated ones. The board then presented a cleaner, more unified list of events.

Step 2 - Building the Timeline

The next step was to arrange the events chronologically from left to right. This visual timeline reveals the sequence in which events occur. Frank, Katie, and Marlon rearranged the notes swiftly. In the end, four distinct sequences appeared on the board.

At this point, Peter noticed similar terms within the sequences-like Buyer and Client.

• “What is the difference between them?” he inquired.
• Frank explained, “SHELF began as a wholesaler supplying restaurants, hotels, and smaller bookstores. Our business partners were called Clients because they made large orders and paid on credit. Buyers are retail customers who pay immediately. In our new ecommerce system, we’ll stick to these terms.”
• “You probably don’t know this, but you’ve already built something called a Ubiquitous Language,” Peter remarked with a grin. “It’s a shared vocabulary among everyone involved in a project. Are you all really using these terms consistently?”
• “Absolutely,” Frank confirmed. “It’s crucial to be specific when dealing with different types of customers.”

Step 3 - Introducing Commands

Commands, unlike Events, represent intentions - actions that may or may not happen. When naming Commands, we use the present tense to emphasize that they’re about to occur. Blue sticky notes indicate Commands.

Peter then asked the team to place Commands alongside their corresponding Events in the timeline for the online selling process.

You can see how Commands and Events are now paired in clusters (like Buyer, Cart, Order). These clusters are known as Aggregates in both Event Storming and Domain Driven Design.

Step 4 - Defining Aggregates

Aggregates group related Commands and Events together, reflecting the boundaries of state changes in the system. They are represented with pale yellow sticky notes.

Underneath, an Aggregate manages the state of its underlying entities. Each entity can be uniquely identified and undergo changes. Think of an entity as a database row paired with its object. An Aggregate ensures that only its own entities are modified during a state change, if a change must be communicated across Aggregates, Events will trigger that notification.

Even if a state change fails, an Event might still fire to signal that something went awry, prompting necessary reactions elsewhere in the system.

Step 5 - Identifying Actors

Every Event is triggered by a reason - often a user or a system - dispatched Command. In Event Storming, users are known as Actors, marked by a small sticky note attached to the corresponding Command. This notation also helps UI and UX teams visualize the scope of their work.

For system-dispatched Commands or those executed inside an Event Subscriber, we introduce policies. They are denoted by purple sticky notes.

Step 5a - Policies

Policies act like conditional statements, defining whether something should happen or not. Let’s add some policies to our board for clarity.

Buyer Policy

• A Buyer can only be registered if their email address is not already in the Store database.

Cart Policy

• The Cart must not exceed 20 items.
• If the Buyer spends more than 100 money units, they receive free delivery.

Order Policy

• A Buyer can only check out if the Cart value is over 50 money units and is not empty.
• Until an order is paid or payment is pending, the Buyer can still modify it.
• The cancellation policy ensures no payment is in process, and once paid, a refund process is initiated.
• Additionally, the order cannot be finalized if any payment is ongoing.

Step 6 - Flagging Issues

Not every Aggregate easily fits onto the board. In SHELF’s case, their invoicing process was already managed by an existing system. Frank was uncertain how it should integrate with the new system or whether the invoice should be generated automatically or upon request.

Red sticky notes flag such issues - they draw attention to areas needing further discussion.

It’s now up to SHELF to clarify these details during follow-up discussions.

Step 7 - Integrating External Systems

To speed up development, Peter and the team decided to outsource book reviews to an external system. This system provides easy-to-embed code snippets along with all necessary mechanics and logic.

Step 8 - Crafting Views

Views are the interfaces presented to the user. They show the available options and functionalities. The design details of these views are ultimately the responsibility of the UI/UX team.

Glossary

• Event: An occurrence in the past that shapes the Domain, typically expressed in past tense.
• Command: An instruction or intention in the present tense aimed at triggering an Event.
• Aggregate: A cluster of related Commands and Events that manage state changes within defined boundaries.
• Actor: A user or system initiating a Command.
• Policy: A condition or rule that governs whether an action should occur, indicated by specific sticky note colors.

Summary & Next Steps

During the workshop, we introduced the basic building blocks of Event Storming. The SHELF team left the session enthusiastic, having delved deep into their Domain and uncovered new insights about their business. For Peter, it was yet another successful session where he rapidly distilled crucial business facts, ensuring everyone was on the same page.

Event Storming, with its simplicity and flexibility, is an exceptionally effective way to model a Domain, especially in early project phases. As an architect, feel free to adapt and extend this vocabulary to cover any additional nuances in your Domain. Once you’ve built the foundation, why not try a mini-session on your own? Experiment with your own domains, iterate, and refine the process to suit your needs better.

For further exploration, consider diving into more detailed materials on Domain Driven Design (DDD) and advanced facilitation techniques.