Demystifying Event Storming: Process Modeling Level Event Storming (Part 2)

Welcome to Part 2 of our journey into the world of Event Storming, the innovative technique that promises to untangle the complexity of any domain. In Part 1 Now, we’ll build upon the foundations we laid in our previous installment as we delve deeper into the key principles and techniques of Event Storming. Let’s pick up where we left off and continue our quest to master this invaluable tool for understanding complex systems.

Order Matters

The sequence of events on the wall reflects the chronological flow of activities within your business domain. It provides context and clarity, allowing participants to visualize how one event leads to another. This contextual flow aids in identifying cause-and-effect relationships.

Put different events side by side to show two possible paths. We place events, like Rent is Accepted and Rent is Canceled, next to each other. This helps us see and understand the different ways customers might go through the campervan renting process. It’s like creating a clear picture of the different stories that can happen, making it easier to explore and plan for all possibilities in our campervan domain.

In continuing, what happens after the rent is canceled? What if the cancelation is possible only after rent is requested? If no one raises a point, then maybe we could clarify it with a product manager. Finally, if a rent is canceled, then the Client is returned to the very beginning of the renting flow.

Definitions

As we discussed before, those big white sticky notes labeled Definitions are important for pointing out key business words. While the orange sticky notes are like the main characters in Event Storming, Definitions are the basic building blocks of the Ubiquitous Language.

In an event storming session, if there’s a business term, acronym, or even casual slang mentioned, encourage the person who brought it up to jot it down and put it on the wall near the events. This simple step promotes active participation in the storming process and often sparks new questions and discussions among the group.

Ensure that these definitions are clear, relate to the specific context, and cover any conditions, roles, or dependencies involved. Here are some of the definitions we’ve encountered up to this point:

Storytelling

Storytelling in Event Storming is a powerful technique that adds a narrative dimension to the collaborative modeling process. Instead of just focusing on abstract events, commands, or aggregates, storytelling allows participants to explore the system’s behavior in a more contextual and real-world manner. Storytelling helps place events and interactions in a real-world context. By creating stories around specific scenarios, participants can better understand how the system behaves in different situations.

Participants can use storytelling to explore various scenarios or user journeys. This involves describing the sequence of events and commands that occur in response to specific user actions or external events. It encourages participants to take on different user perspectives. This helps in identifying and understanding the needs, motivations, and goals of various actors within the system.

Stories provide a richer context for discussions. Participants can talk about concrete situations instead of just discussing abstract concepts, making it easier to uncover potential issues, requirements, or improvements. Through storytelling, participants can explore edge cases and exceptions that might not be immediately apparent. This ensures a more comprehensive understanding of the system’s behavior under different conditions.

Stories can be continuously refined and updated as the modeling session progresses. This iterative process allows for the incorporation of new insights and adjustments based on ongoing discussions. Also, It engages participants on a more emotional level. It encourages empathy towards end-users and stakeholders, fostering a deeper understanding of the impact of system behavior on real-life scenarios. In the end, By collectively crafting and discussing stories, participants align their mental models and ensure a shared understanding of how the system functions in practical terms.

Using storytelling, you can go through domain events and create different narratives to verify that you haven’t missed anything. - Alberto Brandolini

In our Domain, Imagine a traveler named Sarah, excited about her upcoming campervan adventure. She decides to rent a cozy campervan from the Munich gateway for a week of exploration. As she browses through the options, she adds a portable toilet and a camping table to her booking for extra comfort. Related Events Unfold:

1. Renting Initiated:

   • Sarah initiates the renting, picking Munich as her starting point.

2. Equipment Added:

   • She decides to enhance her adventure by adding a portable toilet and a camping table to her rental.

3. Renting Accepted:

   • With a click of a button, Sarah’s renting is confirmed, and she’s ready for her journey.

During an Event Storming session, participants can vividly describe Sarah’s journey. They might place sticky notes on a board, representing events like “Renting Initiated,” “Equipment Added,” and “Renting Accepted.” This storytelling approach helps the team visualize the user’s actions, understand the flow of events, and discuss potential improvements or considerations. Potential Discussion Points:

• The team might discuss how the system handles equipment additions during a rental.
• They could explore scenarios where users modify their renting or inquire about additional equipment.
• The storytelling prompts discussions about the user experience, system responses, and potential challenges.

This simple narrative creates a shared understanding among team members, emphasizing the importance of considering user perspectives and refining the system based on real-world scenarios. It transforms technical discussions into a collaborative adventure, ensuring the software meets the needs of adventurous travelers like Sarah.

Sub-Domains

Once you see the big picture, you can start group events and identify sub-domains and boundaries. Sub-domains are like separate areas in your business, each one focusing on a specific part and using its own set of terms and rules. It’s a bit like having different rooms for different things in your house. Now, the people who really know their stuff about the business, we call them domain experts.

Finding sub-domain boundaries, therefore identifying clear bounded contexts, is one of the key benefits of Domain Driven Design. - Alberto Brandolini

They’re the ones who help draw lines around these areas, saying, “This is where we talk about rents,” or “This is where we manage our campervan availability.” By letting these experts set the boundaries, we make sure that our system is organized in a way that makes sense for how the business actually works. It’s like getting advice from the pros to build a system that fits the real-world needs of our campervan rental business.

Note: If a team starts using a new term to express an existing concept or an existing term is used to express a new meaning, then it is a red flag for the team that the subdomain’s boundaries are overlapping.

In our domain, distinct sub-domains can be identified to encapsulate specialized aspects of the business. One such sub-domain could be Renting Management, which focuses on the reservation process, confirmation, and cancellations. Another vital sub-domain may be Inventory Management, which is responsible for overseeing the availability of campervans and associated equipment. Each of these sub-domains operates within its own defined context, utilizing specific terminology and rules. By delineating these sub-domains, the campervan rental system becomes modular, fostering clear understanding and efficient development as stakeholders collaborate effectively within their designated areas of responsibility.

In the Rent Management sub-domain, we have events like Rental Order Placed, Rent Confirmed, Rent Canceled, etc. Also, in our Inventory Management sub-domain, we have events like Campervan Reserved, Campervan Released, Item Out of Stock, etc. Now, let’s identify the intersections. One of the shared events is Confirmation of Reservation; this event is critical for both sub-domains. In the Rent Management sub-domain, it signifies the successful confirmation of a customer’s reservation. The Inventory Management sub-domain indicates that the reserved campervan and equipment need to be marked as unavailable.

Exactly In fact, When a customer’s rent is confirmed, both the renting status in the Renting Management sub-domain and the availability of reserved items in the Inventory Management sub-domain need to be updated simultaneously.

Then what is the solution? First, let’s collaborate effectively. Bring together stakeholders from both sub-domains for a collaborative discussion. Involve domain experts, developers, and any relevant team members. It’s time to clearly define domain events related to “Campervan Pickedup” in each sub-domain. For example, “Renting Confirmed” is in the “Renting Management” sub-domain, and “Campervan Picked Up” or “Equipment is reserved” is in the “Inventory Management” sub-domain. Implement a mechanism for event synchronization between the two sub-domains. When a rental is confirmed, an event triggers the update of the campervan’s availability status.

Also, ensure transactional consistency. Implement a solution where both the renting confirmation and the update of inventory availability occur within the same transaction, ensuring that the system remains in a consistent state. Address potential errors or failures during the event synchronization process. Implement error-handling mechanisms to gracefully manage issues like network failures or database errors.

By implementing these practical steps, you create a solution that ensures the seamless handling of campervan pickups across both the “Renting Management” and “Inventory Management” sub-domains. The collaborative approach, clear definition of events, and robust technical implementation contribute to an effective resolution of the intersection between these sub-domains.

Imagine two teams working together: one team handles renting reservations, and the other team manages the inventory of campervans and equipment. Now, there’s a special moment when someone's reservation is accepted. Let’s name this event “Rent is Accepted.”

When this event occurs, it’s not just good news for the inventory team to get ready. They have their own event called “Equipment Reserved.” This event means that specific equipment is set aside for the confirmed rent.

Now, here’s where the magic of Event Synchronization happens. The two teams coordinate so that when “Rent is Accepted” lights up on one side, “Equipment Reserved” starts shining on the other. It’s like synchronized fireworks – both beautiful and in perfect harmony.

This synchronization ensures that everyone knows what’s going on. The booking team and the inventory team are like dance partners moving together. By doing this synchronized dance, they make sure that the campervan adventure starts on the right foot – with a confirmed rent and the right gear ready for the journey. Event Synchronization is their secret weapon for making the campervan experience seamless and enjoyable for every traveler.

It’s crucial to avoid confusion between sub-domains and bounded contexts. Let’s clarify: Sub-domains are like different rooms in our campervan headquarters. Each room has its own focus, using specific terms and rules. For example, we have a room for handling renting and another for managing inventory.

Bounded contexts, on the other hand, define the rules and meaning of terms within a specific area. Imagine it as a set of guidelines for how things work in each room. So, while the “Renting” term may mean one thing in the renting room, it could mean something else in the inventory room.

The key is to understand that sub-domains are like separate areas, each with its own focus, while bounded contexts set the rules within those areas. This distinction helps us navigate our campervan world smoothly, ensuring that everyone is on the same page without getting lost in terminology. For more, read the awesome article written by Nick Tune.

Process Modeling

In our journey so far, we kicked things off by crafting a big picture for our domain. Imagine it as a vibrant story unfolding on a large canvas, using colorful sticky notes to showcase the major domain events and connections within our complex system. Like skilled storytellers, we painted the broader strokes of our narrative, defined and resolved conflicts of sub-domains, and captured the essence of our domain’s adventures.

Now, as we venture into the next chapter of our exploration—process modeling—we’re turning our focus to the intricate details within our specific domain. It’s like zooming in on the individual scenes of our story, using our trusty sticky notes to illustrate the step-by-step sequences, actors involved, and decision points.

Process modeling can be used to model an epic or set of features. — Alberto Brandolini

Just as we appreciated the grand view of our domain’s landscape with the big picture, process modeling allows us to examine the finer details. Our sticky notes become like little explorers, helping us uncover the nuances of how our domain operates on a more granular level. It’s like adding a magnifying glass to our storytelling toolkit to understand the tiny elements that make our domain unique.

In the dynamic realm of software design, event storming emerges as more than a methodology—it’s a color puzzle that unravels the intricate threads of our campervan adventure. Much like assembling a mosaic of hues to reveal a breathtaking image, Event Storming brings clarity and coherence to the complexity of system interactions.

A business process is a chain of commands handled by systems and events reacted to by automated or manual policies — Alberto Brandolini

So, in this next leg of our adventure—process modeling—we’ll delve into the specific processes within our domain, bringing them to life with details. It’s an exciting journey akin to exploring the intricate scenes of our story within the vast world of our domain, one sticky note at a time!

Commands

In the fascinating world of campervan adventures, commands take center stage in orchestrating the dynamic interactions within our domain. Let’s explore how commands play a pivotal role in shaping the narrative of our campervan booking system.

A Command is a decision taken by a user or piece of software. It’s a verb with an imperative form. The most frequent Command triggers are users, and in Event Storming, they are modeled with Actors pattern.

Commands are the directives that spark actions within our system. While events narrate the story of what has occurred, commands articulate the explicit instructions for the system to follow. Mastering the modeling of commands allows us to craft a more nuanced and responsive representation of our campervan booking processes.

In the Event Storming process tailored for our campervan domain, commands manifest as essential prompts for actions. These commands are portrayed as distinctive light blue sticky notes strategically placed to the left of the events they set into motion.

Imagine a scenario where an adventurer initiates a renting process. The command “Request Rent” is represented as a blue sticky note.

The effective modeling of commands in Event Storming is instrumental in capturing the intended actions within a system. By embracing this aspect of the process, teams can foster collaboration and build a more accurate and responsive representation of the domain.

Actors

The portrayal of an actor in event storming is represented by a compact yellow sticky note, embodying a user initiating a specific command. Notably smaller than other quadrants, such as orange events or blue commands, the size of this sticky note underscores its distinct role in the overall Event Storming process. We don’t need to overload the whole picture by pinning an Actor to every event, but just enough to eliminate ambiguities.

Read Models

In the vibrant canvas of campervan Event Storming, the “Read Models” unfold as essential green stickies, each harboring insights into our domain’s intricate details. Let’s delve into the significance of these green gems and how they enrich our understanding of campervan adventures.

Read Models, represented by the verdant hue of green stickies, serve as informational repositories. They encapsulate valuable data and projections that offer a snapshot of the current state within our campervan domain. Positioned strategically amidst the dynamic landscape of events, commands, and actors, Read Models empower stakeholders to glean real-time information without altering the system’s state. They act as lenses, providing specific perspectives on crucial aspects of our campervan ecosystem.

An example Read Model in our domain is Campervan Availability. Imagine a green sticky labeled Campervan Availability. This Read Model dynamically reflects the real-time availability status of campervans at various locations. It consolidates information, allowing stakeholders to assess availability without triggering commands or altering rentings.

Also, Read models are used to represent the state of the system after an event has occurred. Read Models capture the information or state of the system that stakeholders can query without changing the system’s state. For example, Imagine a scenario in our campervan adventure where an enthusiastic traveler selects a drop-off station for their journey. Following this event, the Campervan Availability Read Model comes into play. This green sticky, strategically positioned after the event, reflects the real-time status of campervan availability at the selected drop-off station.

Read Models offer instant access to critical information, fostering informed decision-making without perturbing the system. Also, by incorporating Read Models, our Event Storming process aligns with a user-centric design, providing stakeholders with tailored views based on their informational needs.

Policy

A policy provides a structured framework. These policies take on a formalized structure, resembling statements such as Whenever…X, then…Y or If…X, then…Y, indeed, it’s a reaction to an event.

The idea is: whenever Event, then Command.

Imagine a scenario where a fleet of campervans converges at one of our popular drop-off stations, let’s call it “Munich.” The Rent Limits Policy steps in with a simple yet powerful rule: “If the number of rented campervans at Munich exceeds the predefined limit, then new rental requests for that station are temporarily suspended until availability is restored.”

This policy ensures that each drop-off station maintains its charm and functionality. By halting new rentals when a location approaches capacity, we prevent overloading and guarantee that every traveler can embark on their adventure with ease. It’s about fairness, ensuring that the magic of our campervan experience is spread evenly across all the enchanting drop-off stations in our network.

So, as you plan your next escapade, rest assured that the Rent Limits Policy is hard at work, orchestrating a harmonious dance of rentals, ensuring every traveler gets to experience the wonder of our campervans without compromise.

External Systems

In the bustling landscape of event storming, our campervan adventure extends beyond the borders of our immediate ecosystem. External systems, denoted by pink sticky notes, emerge as key players, influencing and interacting with our campervan operations. Pink, the color of collaboration and connectivity, symbolizes external systems in event storming. These systems, whether third-party services, APIs, or external databases, contribute to the richness of our campervan experience.

Imagine our campervan reservation system collaborates with an external navigation service. When a user plans a trip, the pink sticky note represents the interaction. The external system provides real-time navigation suggestions based on road conditions, traffic, and points of interest, influencing the campervan’s route decisions.

Or, to enhance the cost-aware traveler experience, our campervan ecosystem integrates with an external Fuel Price API. The pink sticky note denotes this collaboration, where the system regularly fetches current fuel prices for various locations, influencing decisions related to refueling.

Understanding the role of external systems is pivotal. It allows us to anticipate dependencies, design robust interfaces, and craft a campervan experience that seamlessly integrates with the broader technological landscape.

Conclusion

As we wrap up this leg of our journey through Event Storming, we’ve explored the vibrant tapestry of our campervan adventure. From the big picture to details, each sticky note has added a layer to our story.

Commands, Actors, Read Models, and Policies have been part of shaping the processes that make our campervan system come alive. But this isn’t the end; there’s more to uncover. Part 3 is on the horizon, promising insights into identifying aggregate roots and unveiling the rest of our adventure.

So, stay tuned for the next chapter. Let the colors of Event Storming guide you through the landscapes of our campervan world. Here’s to a journey of clarity, collaboration, and ongoing discovery.