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.

Color	Meaning	Description
	Domain Event	Something that happened in the domain that is meaningful and immutable.
	Command	A request for the system to do something (may succeed or fail).
	Aggregate	Core domain logic that ensures business rules and consistency.
	Actor	Initiates commands; typically a user or external role.
	Policy	Business rule that reacts to events and issues commands.
	External System	A system or service outside the domain boundary.
	View	A projection or model optimized for querying and UI.
	Issue	A problem, uncertainty, or area needing clarification.

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.

Event storming board - raw events

[Buyer Registered]   [Book Accepted]       [Book Stored]
[Book Ordered]       [Payment Requested]   [Payment Completed]
[Order Cancelled]    [Book Reviewed]       [Invoice Requested]
[Invoice Issued]     [Cart Emptied]        [Delivery Scheduled]

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.

Timeline, left to right

Acceptance      Storage          Online Store        Accounting
-----------     ------------     ---------------     ---------------
Book Arrived -> Book Accepted -> Book Published  -> Invoice Requested
                              -> Cart Created    -> Invoice Issued
                              -> Book Ordered
                              -> Payment Completed
                              -> Delivery Scheduled

Reviewing
---------
Book Purchased -> Review Posted -> Review Published

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.

Command -> Event pairs

Register Buyer        -> Buyer Registered
Add Book to Cart      -> Book Added to Cart
Checkout Cart         -> Order Placed
Request Payment       -> Payment Requested
Confirm Payment       -> Payment Completed
Cancel Order          -> Order Cancelled
Post Review           -> Review Posted

You can see how Commands and Events are now paired in clusters (like Buyer, Cart, Order). In Event Storming, these clusters are candidates for Aggregates. In Domain-Driven Design, an Aggregate is confirmed only when it also makes sense as a consistency boundary for state changes.

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.

Aggregates on the board

+------------------+----------------------+----------------------+
| Aggregate        | Commands             | Events               |
+------------------+----------------------+----------------------+
| Buyer            | Register Buyer       | Buyer Registered     |
| Cart             | Add Book to Cart     | Book Added to Cart   |
| Order            | Checkout Cart        | Order Placed         |
| Payment          | Request Payment      | Payment Completed    |
| Review           | Post Review          | Review Posted        |
+------------------+----------------------+----------------------+

Underneath, an Aggregate manages the state of its entities and value objects. Each entity can be uniquely identified and undergo changes. Think of an entity as an object with identity, not just a database row. An Aggregate protects invariants inside its own boundary; if a change must be communicated across Aggregates, Events can carry that fact to other parts of the system.

Domain Events usually describe facts that already happened successfully. Failures can also be modeled as events when the business needs to react to them, but they should be named explicitly as failure outcomes instead of being emitted as if the original state change succeeded.

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.

Actors dispatching commands

Buyer
  -> Register Buyer
  -> Add Book to Cart
  -> Checkout Cart
  -> Post Review

Payment Agent
  -> Confirm Payment

Store Employee
  -> Accept Book

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.

Buyer policy

Register Buyer
  -> check email uniqueness
  -> Buyer Registered

Cart Policy

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

Cart policies

Add Book to Cart
  -> reject when cart already has 20 items
  -> Book Added to Cart

Checkout Cart
  -> apply free delivery when cart value is over 100 money units
  -> Order Placed

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.

Order policies

Checkout Cart
  -> require cart value over 50 money units
  -> require cart not empty
  -> require no payment already in progress
  -> Order Placed

Cancel Order
  -> block cancellation while payment is in progress
  -> start refund when order was already paid
  -> Order Cancelled

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.

Issue note

[Issue]
Invoice generation belongs to an existing external process.
Decision needed: automatic generation or buyer-requested generation?

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.

External system integration

Review Context
  -> Request Book Review Widget
  -> External Review System
  -> Review Widget Embedded

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.

Views

Buyer Account View
  - registration status
  - order history
  - posted reviews

Cart View
  - selected books
  - cart value
  - delivery price

Order View
  - payment status
  - delivery status
  - invoice action

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.