Event Storming as an Architectural Tool

Event Storming is a collaborative and highly visual approach used in software development to understand complex systems and design architectures. It is primarily employed in Domain-Driven Design (DDD) and helps teams map out business processes and systems by focusing on events that trigger actions within a system. By using Event Storming as an architectural tool, teams can create a shared understanding of the system’s domain, identify key components, and uncover hidden requirements. Here’s how Event Storming can be applied effectively as an architectural tool.

The Basics of Event Storming

Event Storming begins with a broad, open-ended exploration of the system’s events. Events are typically things that happen within the system that are significant to the business and often result in a change of state. For example, in an e-commerce system, events could include “Order Placed”, “Payment Processed”, or “Shipment Shipped.”

The core idea is that by identifying these events, teams can create a visual map of how the system behaves, the flow of data, and the dependencies between different components. The visual nature of Event Storming makes it easier to spot bottlenecks, misunderstandings, or gaps in the system’s design.

Key Elements of Event Storming

1. Domain Events: The events that happen in the system, representing a significant change in state. These are typically represented by orange sticky notes in the Event Storming workshop.

2. Commands: Actions that trigger domain events. Commands are usually represented in blue sticky notes. These actions are initiated by a user or another system.

3. Aggregates: The core components or entities of the system that process commands and trigger events. Aggregates often have consistency boundaries and are responsible for enforcing business rules.

4. Read Models: The way data is retrieved or queried, often optimized for specific use cases. These are represented with green sticky notes.

5. External Systems/Boundaries: Systems or boundaries outside the current domain that interact with the system. These are typically represented with purple sticky notes.

6. Policies: Business rules or triggers that respond to certain events and may invoke additional actions. These might include workflows, user notifications, or external service calls.

The Process of Event Storming

Event Storming is done in a collaborative, hands-on workshop style. Here’s how the process usually unfolds:

1. Gather Stakeholders: Assemble a group of stakeholders, including developers, business analysts, domain experts, product managers, and even customers. The diversity of the group helps surface different perspectives.

2. Define the Scope: Agree on the boundaries of the system you’re modeling. This could be a feature, an entire domain, or a specific business process. The scope will help focus the conversation.

3. Identify Domain Events: The team begins by brainstorming domain events. They can be written on sticky notes and placed on a wall or large board. The focus should be on events that are meaningful to the business and trigger changes in state.

4. Identify Commands: Once domain events are identified, the team looks for commands that could trigger those events. Commands might come from users, external systems, or other processes within the application.

5. Group and Organize: As the team identifies more events, commands, and aggregates, they start to group related components together. This organization helps visualize the system’s flow and interactions between components.

6. Refine and Iterate: The map is continuously refined through discussion and iteration. The team identifies missing events, changes to business logic, and adjusts their model as needed.

Event Storming in Architecture

As a tool for architecture, Event Storming provides a holistic view of how components interact within a system. It promotes the creation of well-defined boundaries (or bounded contexts) that help organize the system and avoid unnecessary complexity. By focusing on events, teams are able to identify both the immediate and long-term effects of system actions.

Here are some of the ways Event Storming helps with system architecture:

1. Defining Bounded Contexts

In Domain-Driven Design, a bounded context is a boundary around a specific part of the system where certain rules and models apply. Event Storming helps identify these contexts by mapping out the flow of events across different components. This ensures that each part of the system is well-defined and operates independently, without unintended side effects.

For example, in an e-commerce system, the ordering context might be separated from the payment context. By mapping the events within each bounded context, the team can establish clear rules about which components should interact and how.

2. Uncovering Dependencies and Interactions

Event Storming helps surface the dependencies and interactions between components that might otherwise be overlooked. This is crucial when designing a system’s architecture. If the flow of events is not well understood, components may become tightly coupled or interact in ways that are difficult to maintain.

For example, during an Event Storming session, the team might discover that a particular service depends on multiple other services to process an event. Identifying these dependencies early can lead to a more modular architecture with clear boundaries between components.

3. Optimizing for Scalability

Event Storming also allows architects to see how different parts of the system scale. Some events might trigger high-frequency actions, while others could be less frequent. By mapping out these events and understanding their triggers, the team can design a system that handles scaling effectively.

For instance, an event like “User Registered” may be a high-frequency event in a large-scale system. By identifying such events, the team can ensure that the system can handle spikes in load without performance degradation.

4. Identifying Event-Driven Architecture Opportunities

Event Storming naturally leads to an event-driven architecture (EDA) design. An event-driven system allows components to react asynchronously to events, improving system responsiveness and scalability. Event Storming highlights which events are significant enough to trigger actions across the system.

For example, in a financial application, the event “Transaction Completed” could trigger multiple actions in other systems, such as updating a customer’s balance, sending notifications, and generating reports. An EDA approach ensures that each of these tasks is handled independently, without blocking other processes.

5. Encouraging Collaboration and Shared Understanding

The visual nature of Event Storming encourages collaboration and ensures that all stakeholders, both technical and non-technical, share a common understanding of the system. When everyone can see the flow of events and how they connect to each other, it fosters better communication between the business and development teams.

For instance, if a business stakeholder can see how a customer’s order triggers several downstream events in the system, they can better understand the system’s performance, potential bottlenecks, and user experience.

Benefits of Event Storming as an Architectural Tool

1. Improved Communication: By using a shared visual representation of the system, teams can discuss and resolve misunderstandings quickly.

2. Early Problem Detection: Event Storming helps identify potential architectural issues early in the design process, such as unnecessary dependencies or missing business logic.

3. Faster Iterations: The hands-on, interactive nature of Event Storming allows teams to iterate quickly, making it easier to adjust designs as new insights emerge.

4. Aligned Design and Business Goals: Event Storming helps bridge the gap between business goals and technical solutions, ensuring that the architecture is designed to meet real-world needs.

5. Clearer System Boundaries: By mapping out events and dependencies, Event Storming naturally leads to clearer system boundaries, which simplifies maintenance and scalability.

Conclusion

Event Storming is an invaluable architectural tool that provides a deeper understanding of how a system behaves. It enables teams to collaborate effectively, identify dependencies, and create architectures that are well-aligned with business needs. By focusing on events as the driving force of system behavior, Event Storming offers a clear and actionable approach to building scalable, maintainable, and flexible systems.