Demystifying Event Storming: A Comprehensive Guide to Understanding Complex Systems (Part 1)
This guide is your roadmap to mastering Event Storming for architects, analysts, and curious minds, offering insights into unraveling the secrets of complex systems.
Join the DZone community and get the full member experience.Join For Free
Event Storming, a dynamic and collaborative modeling technique, emerges as a guiding light in the fog of complexity. It’s not just a method; it’s a voyage of discovery, a shared language, and a bridge between stakeholders, software developers, and business experts.
Picture a journey that takes you deep into the heart of your organization’s inner workings, unveiling the complex details of how things operate and replacing confusion with clear understanding. Event Storming promises precisely that and more. This method has left a significant impact in areas like software development, domain-driven design, and more.
But what is Event Storming, and why is it gaining momentum in various industries? How can it be harnessed to gain a profound understanding of complex systems and domains? This comprehensive guide seeks to demystify Event Storming, bringing it into the spotlight and equipping you with the knowledge to navigate this powerful tool.
To continue, I’ll talk about the concept of Event Storming, exploring its origins, key principles, and practical applications. You’ll discover how it differs from traditional big design up-front methods.
Event Storming isn’t exclusive to software developers; it’s a technique that brings together individuals from various domains, creating a shared language and a platform for understanding even the most intricate systems. Whether you’re a seasoned software architect, a business analyst, or a curious explorer, this guide is designed to equip you with the tools to embark on an Event Storming journey.
Prepare to immerse yourself in a world of colorful sticky notes, dynamic discussions, and enlightening revelations. Let’s demystify Event Storming and start a voyage to uncover the secrets of complex systems, one event at a time.
Big Design Up Front
Big Design Up Front (BDUF), also known as Waterfall or Traditional Software Development, is an approach to software development where a comprehensive and detailed design of the entire system is created before any coding or implementation takes place. It’s a method that was commonly used in the early days of software development.
But, In today’s fast-paced business environment, user needs and project requirements can change frequently. BDUF assumes that all requirements can be known and defined upfront, which is often not the case. As a result, projects following BDUF can struggle to adapt to changing requirements. Also, BDUF creates a rigid plan that can be challenging to change once the project is in progress. Any deviations from the initial design can lead to costly rework, project delays, and increased complexity.
Finally, BDUF has become less popular in favor of more agile and iterative development methodologies. Modern approaches, like Agile and Scrum, prioritize adaptability, customer feedback, and delivering working software in smaller, more manageable increments. These methods align better with the dynamic and evolving nature of software development in the 21st century. Incremental design is the best alternative to BDUF. Next, I’ll detail how it fixes almost all of the issues of BDUF.
Imagine you have a business much like the famous Roadsurfers. They had these cool campervans, perfect for going on adventures. But what made them really special was how you could pick up and drop off these campervans at different places. Think of it like magical gateways: Munich, Paris, Porto, and Madrid. And the best part? You could return the campervan to any of these places.
But the adventure didn’t stop there. They had all sorts of extra stuff you could take with you. You know, things like portable toilets, comfy bed sheets, warm sleeping bags, and even camping tables and chairs. It was like a treasure chest of goodies for travelers. You could choose whatever you wanted to make your journey comfy and fun.
Now, here’s the fun part. You could book any of these goodies in addition to your campervan. So, if you needed a cozy set of bed sheets for a good night’s sleep, you got it. The catch was that there were only a certain number of these goodies at each place. When someone drove off with some equipment, the stock went down. But when they returned, it went back up.
Lastly, there were these things called rental orders. When someone wanted to go on an adventure, they made a rental order. It was like a checklist. First, they picked their campervan. Then they said where they were starting and ending their adventure. They also told us when they were setting off and when they’d be back. And to make things just right, they picked what extra stuff they wanted to take. For example, someone might say, “I’ll take one set of bed sheets, please.”
Event Storming is a powerful and collaborative workshop-based technique used to gain a deep understanding of complex systems, processes, and domains. It was introduced by Alberto Brandolini, an expert in domain-driven design and Agile software development. Event Storming stands out as a versatile and practical approach that brings together stakeholders, domain experts, software developers, and business analysts to unravel the intricacies of a system.
At its core, Event Storming is a visual modeling method that uses sticky notes and a large workspace, such as a wall or whiteboard, to represent various events and interactions within a system. These events can range from user actions, system processes, and domain events to business rules and policies. The workshop participants collaboratively contribute to this visual representation, creating a shared understanding of the system’s behavior and business processes.
Event Storming starts with a domain description, then Big Picture. Big Picture Event Storming is the first step in understanding complex systems. It’s like creating a big, simple map of the whole system to see how everything fits together. Imagine a big wall covered in sticky notes that show the main things happening in the system and who is involved.
First of all, decide on the boundaries of the business domain you’re gonna discover. On a big-picture event storming, you may tackle the whole business or narrow down your focus to specific subdomains. Understanding the scale will help you to define the invitee list. The key to a successful event-storming session lies in the participants and their knowledge.
For a successful event-storming session, it’s essential to bring together individuals with the appropriate knowledge and roles. This includes those who ask questions, such as solution architects, software engineers, and DevOps specialists, as well as those who provide answers, like decision makers, business owners, and domain experts. The ideal number of participants might vary depending on your specific business needs, but I’ve found that having 8–10 participants is usually the best balance. It’s advisable to diversify the group by their areas of knowledge and expertise. This way, the group collectively holds a deep understanding of the business domain you aim to explore.
Before we begin, a quick reminder: Let’s all remember that our primary goal at this stage is to explore the domain model and understand the big picture. Not in technical terms, but focus on what we will achieve here for organization.
Now, make sure you have the required materials ready. You’ll need a room with a wall that spans at least 8–10 meters in length, and larger is even better. Additionally, you’ll want a roll of paper that matches this length, measuring around 70–100 cm in height, and a good supply of sticky notes. An affordable white plotter paper roll is an excellent choice for this purpose. Simply unroll the paper onto the wall, and that’s where the sticky notes will go.
All participants should have a marker, and each sticky note should be used to write a single concept in capital letters. Even more important is the need to strictly adhere to the timeline. It’s important that it’s explicitly clear what occurs before and after each event.
Domain Event represents a significant occurrence or incident within a specific domain. It captures an event that holds relevance to the domain’s operations, often reflecting a change in the system’s state or a notable action. Domain Events help in mapping out the dynamics and behaviors of your domain. These events serve as building blocks for understanding and modeling complex processes, interactions, and business logic.
To lower the entry threshold for participants, the facilitator usually makes the first step by sticking to pivotal events, which emphasize the major happenings in the business from end to end.
Domain Events must be written in past tense.
Now, let’s see our first library Domain Event:
Now, the participants can start filling the gaps around the pivotals. It is the most important part of the whole storming, where the common goal is to share maximum domain knowledge from each participant.
Encourage an atmosphere of creativity and knowledge sharing during the initial phase. Let the domain experts write down events and place them on the wall without immediate validation. Even if the events are expressed in lengthy sentences, not yet in the past tense, or if there are duplicates, refrain from interrupting the flow of knowledge exchange and allow people to brainstorm freely.
If you observe participants forming discussion circles, step in to provide support by addressing questions and resolving any challenges. Maintain a highly interactive process, ensuring that everyone remains actively involved for at least 20–30 minutes. It’s important to stress that the events should be arranged chronologically from left to right, even if it’s only partially enforced during the initial phase. This practice contributes to establishing a more coherent and time-ordered event flow.
Hot spot is a pain point or bottleneck that needs further clarification later on. In fact, When you face uncertainties or ambiguities without immediate solutions, it’s entirely acceptable to delay those decisions for later consideration. You can visually depict them on the wall using a distinct purple sticky note. This method helps you track and address these unresolved matters effectively.
After approximately 30 minutes, depending on the domain’s complexity, you may notice the activity slowing down. People might start gazing at the wall or engaging in discussions that don’t result in tangible outcomes on the wall. This serves as an indicator to conclude the first phase and transition to the next stage: the walkthrough.
Currently, most of the domain knowledge has been visualized on the wall. It’s now the moment to clean up, order, and structure it. This is achieved by walking through the wall from left to right, reading aloud the narrative represented on the sticky notes, and engaging in discussions with the authors or knowledge holders to seek clarification and pose questions.
Many of the descriptions may not adhere to the ideal domain event guidelines, which suggest they should be concise statements in the past tense. Additionally, some of them duplicate in meaning or are arranged out of sequence, and a few are grammatically incorrect. Our next step is to traverse the wall and rectify these issues. In the above example, the Campervan Checked Out and the Campervan Handed Over are the same; Both events mark the moment when a customer takes possession of the campervan at the rental station.
Customer Pick-Up for a domain event may lack specificity. It’s not clear where or when the customer picked up the campervan. Was it in Munich, Paris, Porto, Madrid, or any other location? Clarification is needed to pinpoint the exact details of the pick-up event. An Equipment Availability domain event could be unclear in terms of what equipment is available and at which station. It doesn’t specify the type of equipment or the quantity. For instance, if a customer wants to rent camping tables and chairs, there should be a clear event that indicates the availability of these specific items at a particular station.
Following the cleanup phase, we should encourage the experts to take a closer look at the sticky notes and validate the sequence of events. If anything is missed or should be changed here? Well, there is no need to be an expert to see missing events. And the Product Owner could correct you.
In the context of your campervan rental domain, the Ubiquitous Language plays a vital role in facilitating effective communication and mutual understanding among all stakeholders. It serves as a common vocabulary that unifies different perspectives and ensures that everyone involved in the domain shares the same terminology and meanings. The Ubiquitous Language clarifies potentially ambiguous terms like “Station,” defining them with precision.
For example, it distinguishes between a “Station” as a physical location for campervan pickups and returns and a “Station” as a comprehensive operational unit that includes not only the physical location but also the storage of portable equipment and associated services. By cultivating this shared language, event-storming sessions can bridge gaps in understanding, promote smoother discussions, and enhance the overall efficiency of your campervan rental business.
For now, let’s clarify the meaning of Station with a Definition artifact that is written down on a big white sticky note.
Event Storming is a powerful tool for understanding complex systems and domains. It’s more than just a modeling technique; it’s a collaborative journey that brings stakeholders from various domains together to create a shared language. In a world where software development and business requirements are constantly evolving, techniques like Big Design Up Front are becoming obsolete, making way for more agile and adaptable methods.
This is just the beginning. The journey into Event Storming is a multi-part exploration, and the next part is on the horizon. In the upcoming installment, we will delve deeper into Event Storming’s core concepts, practical applications, and its role in domain-driven design. So stay tuned for more insights into unlocking the power of Event Storming in Part 2. Get ready for a voyage of colorful sticky notes, dynamic discussions, and enlightening revelations as you explore the world of Event Storming.
Opinions expressed by DZone contributors are their own.