Event Storming Workshop: A Game-Changer for Mapping Complex Business Domains

Event Storming is an innovative workshop methodology designed to help teams map, visualize, and understand business domains. Using a combination of sticky notes, collaboration, and discussion allows teams to map out the events in a software system and identify areas for improvement. It’s a great way to determine a system’s domain model and align the team on the business rules that drive the system. This powerful technique can be used for both business process mapping and feature discovery in product development. By attending an Event Storming workshop, teams can learn this technique and use it to gain a deeper understanding of the business processes, map user flows that drive their software systems, and unlock opportunities for optimization.

This article will provide an overview of what you can expect from an Event Storming Workshop and how it can serve as a game-changer for mapping and improving your software development and, therefore, services covering various business domains.

The Importance of Aligning Teams on Business Rules

One of the most critical aspects of developing modern IT systems is aligning teams on business domain knowledge. When teams have a clear understanding of the business rules that drive a system, they can make informed decisions about how to design and develop the system. Without this understanding, teams may make assumptions about the business rules, leading to confusion and errors.

The critical complexity of most software projects is in understanding the domain itself.

Eric Evans in Domain-Driven Design

By aligning teams on business processes, everyone has a shared understanding of the system’s requirements and can make decisions based on that understanding. This is crucial for creating a system that meets the needs of the business and its users and usually leads to a more maintainable, evolvable, and coherent system.

DDD Domain-Driven Design

Imagine having a crystal clear understanding of your business domain, down to the tiniest detail. Imagine being able to make informed decisions about how to design and develop your software system, knowing that it will align perfectly with the needs of your business and its users. This is the power of Domain-Driven Design (DDD).

DDD is a software development methodology that prioritizes the importance of understanding and aligning with the business domain. It is a set of principles and practices that guide teams in creating software systems tailored to the business’s unique needs. By creating a shared understanding of the domain model, teams can make better decisions about designing and developing the system, leading to increased satisfaction and success for both the business and its users. DDD is not just about creating functional software; it’s about building software that genuinely serves the needs of the company and its stakeholders. It’s a game-changer for software development. But how can you create that shared understanding of the domain model?

What is Event Storming?

An Event Storming workshop provides a great way to gain that understanding. Event Storming is a collaborative method for visualizing, group learning, and discussing the flow of events in a software system. It is a powerful technique for identifying a system’s domain model and aligning teams on the business rules that drive it.

Event Storming was introduced by Alberto Brandolini, an Italian software developer, and consultant. He shared it in 2013 in his original blogpost as a way to help teams better understand and improve the flow of events in software systems. Through various workshops, talks, and training sessions, he has continued to develop the technique and promote its use. He wrote a book called ‘Event Storming,’ which provides more details about how to use the method and run an Event Storming workshop.

His idea behind Event Storming was to create a more intuitive, visual, and collaborative way of understanding complex systems that is more accessible to non-technical stakeholders and that can be used to align teams on the business rules that drive the system. Brandolini was inspired by Eric Evans’ Domain-Driven Design, which emphasizes the importance of understanding and aligning with the business domain. Event Storming is often used to facilitate DDD practices, and is considered a powerful tool to create a shared experience of the domain model.

Among all approaches to software development, Domain-Driven Design is the only one that focused on language as the key tool for a deep understanding of a given domain’s complexity.

Alberto Brandolini in Event Storming

How Does the Event Storming Process Look Like?

Eventvent storming process starts with creating a large-scale map of the system’s events using sticky notes on a wall. Participants work together to identify the different events that occur within the system and to map out the flow of those events. As the map is built, the team discusses the events and identifies areas for improvement. The process helps to surface implicit knowledge and assumptions and to create a shared understanding of the system’s requirements.

What are Domain Events? (Orange Sticky Notes)

In Domain-Driven Design, a Domain Event is a significant event representing something that has occurred in the business domain. It represents a change in the state of the environment and indicates that something important has happened. Domain events are used to model the system’s behavior and represent the business rules that drive it. They are typically used to describe business-level events, such as a customer placing an order, paying an invoice, or shipping a product.

Domain events differ from technical events, such as a button click, used to model the user interface or infrastructure. The orange sticky notes are the building blocks of the domain model, and they are used to communicate the state of the system to other parts of the system, such as the user interface or other systems. They are used to trigger the execution of business logic, update the system’s state, and generate side effects. They are usually emitted by the aggregates (entities) of the domain model and can be caught and processed by other parts of the system.

Here are some examples of domain events in various domains:

• eCommerce: A customer places an order, a payment is processed, a shipment is dispatched, an order is delivered
• Healthcare: A patient schedules an appointment, a doctor prescribes medication, a lab test is ordered, a test result is received
• Finance: A customer opens an account, a deposit is made, a loan application is submitted, a loan is approved

Actors (Yellow Sticky Notes)

In the context of Event Storming, actors refer to the entities or components within a system or business process that initiate, respond to, or are affected by an event. They represent the “who” is involved in the system, the entities with a role and a responsibility. Actors can be people, sensors, devices, or any other element that interacts with the system. They are used to understand the relationships between different domain events.

Here are some examples of actors in various domains:

• eCommerce: Customer, sales representative, delivery person
• Healthcare: Patient, doctor, nurse, insurance company
• Finance: Bank customer, bank teller, loan officer, auditor

Commands (Blue Sticky Notes)

Another vital component to map during an Event Storming session is commands. Commands direct to the actions that are taken to initiate a change or to trigger a reaction within a system or a business process. They represent the “what” needs to be done and and the specific actions that need to be taken to change the system’s state.

These blue sticky notes are used to identify the initiator of a domain event, the actor responsible for the action and the target of the command, and the element of the system that is affected by the command.

Commands can be of different types, such as user input, external events, system triggers, or any other type of action that initiates a change. During the Event Storming session we map each command on a blue sticky note and place before the corresponding domain event.

Considering domain events from previous section, here are some examples of commands in same domains:

• eCommerce: Place order, cancel order, update order, process payment
• Healthcare: Schedule appointment, cancel appointment, prescribe medication, order lab test
• Finance: Open account, close account, make deposit, withdraw funds

Reactions (Light Blue Sticky Notes)

The next key term is reactions. Reactions refer to the actions or decisions taken in response to a specific event or sequence of events.

These green sticky notes represent different types of reactions, such as business logic, state changes, side effects, or communication with other systems. They are usually represented by light blue (or sometimes purple) colors of sticky notes. They help to understand the flow of data, the flow of control, the responsibilities of different actors, and the relationships between events and entities.

Reactions can reveal potential issues within the system, such as unnecessary complexity, lack of autonomy, or inefficiencies.

Again, if we were to look at some practical examples of reactions, we could list the following:

• eCommerce: Order placed, order updated, order shipped, order canceled
• Healthcare: Appointment scheduled, appointment canceled, lab results received, medication prescribed
• Finance: Account opened, account closed, deposit made, funds withdrawn

Artifacts (Green Sticky Notes)

Artifacts refer to the physical or digital objects created, updated, or deleted due to an event or command. They are the tangible outputs of the system, the elements that are produced, modified, or removed as a result of the actions taken by the event. They can be represented using different types of sticky notes, labels, or symbols, and they are used to understand the flow of data and the changes in the system.

Some examples of artifacts that relate to our domain events examples would include:

• eCommerce: Order, invoice, shipment, customer profile, a message sent to another system, a notification sent to a user
• Healthcare: Appointment, patient record, lab report, prescription
• Finance: Bank statement, deposit slip, check, tax Event a database record

Systems (Pink Sticky Notes)

Pink sticky notes are commonly used to represent external systems or third-party services that interact with the modeled system. These external systems or services can be other internal systems withinEventsame organization or external third-party service providers.

We can list the following examples of systems that are somehow interconnected with our domain events:

• eCommerce: Payment gateway, inventory management system, dynamic pricing model, shipping system
• Healthcare: Electronic health records system, appointment scheduling system, insurance claims system
• Finance: Loan processing system, fraud detection system, accounting system

Policies (Purple Sticky Notes)

In the context of Event Storming, policies refer to the rules and constraints that govern the behavior of a system or business process. These purple sticky notes represent the “who,” “when,” and “where” of things are done, the way the system allows to run specific scenarios. Policies can be of different types, such as business rules, validation rules, security rules, or any other kind of rule that governs the system’s behavior.

Policies can reveal potential issues within the system, such as missing validation, security vulnerabilities, or ambiguities. Also, aligning policies with business rules and making them explicit helps teams to create a cohesive and consistent system.

To understand this naming better, here are some examples of policies in different domains:

• eCommerce: Shipping policy, return policy, privacy policy
• Healthcare: Patient privacy policy, security policy, billing policy
• Finance: Anti-money laundering policy, loan underwriting policy, investment policy

Event Flows (A Sequential Flow of Sticky Notes)

In Event Storming, event flows refer to the sequence of events that occur within a software system or business process. They are used to map out the flow of events and to understand how different events are related to each other. During the Event Storming workshops, we map them simply as a sequential flow of sticky notes.

Event flows are used to identify and understand the different stages of a process, the actors involved, and the business rules that govern the flow of events. They can reveal bottlenecks, inconsistencies, and areas for improvement within the system. By identifying and understanding the event flows, teams can make informed decisions about optimizing the system’s performance.

Event flows are also used in Event-Driven Architecture, where events trigger the execution of business logic and update the system’s state. By understanding the event flows and the relationships between events, teams can design more responsive, flexible, and adaptable systems.

Aggregates and Bounded Contexts

Aggregates and Bounded Contexts are important concepts mapped during Event Storming workshops.

An Aggregate is a cluster of objects that are treated as a unit for the purpose of data changes. It defines a consistency boundary, which means that all changes to objects within an aggregate must be executed atomically. Aggregates also define relationships with other objects, including child objects and references to other aggregates.

A Bounded Context is a set of concepts and terminology that is specific to a particular domain. It represents a context in which a particular model applies. In other words, it’s a way of scoping the boundaries of the model so that it aligns with the boundaries of the business domain. By creating separate bounded contexts, Event Storming participants can ensure that different parts of the system are designed and developed independently, avoiding conflicts and ambiguities in the domain model.

Use Cases for Running Event Storming Session

Developing a Data Strategy

Kicking of data strategy development with data modeling or architecture design is the absolutely wrong direction. Teams that want to build a successful and long-lasting data strategy should start with deep understanding of the business model rather than data itself. Event Storming can be especially useful in developing a data strategy, as teams can visually see how data is managed and stored, and what improvements can be made to streamline the process (e.g., the team can identify areas where data is duplicated, or where there is room for improvement in the data flow).

Deconstructing Monolith Applications into Distributed Systems

Monolithic applications can be difficult to maintain and scale, but deconstructing a monolith into smaller pieces is not that easy either. Event Storming can be used to identify the boundaries between different parts of a system, which can then be separated into smaller, more manageable components.

Event-Driven Architecture

Event-driven architecture is a popular design pattern in modern software development, and Event Storming can be used to understand the events and reactions that drive this type of architecture. The team can use Event Storming to visualize and understand the flow of domain events and reactions, and, therefore to design the underlying event architecture that would drive the system.

Event-Driven Microservices Architecture

With bounded context mapping and data aggregates, the teams can recognize and understand the communication between different microservices in an event-driven architecture. The team can use Event Storming to visualize the flow of events between various microservices and identify areas where the architecture can be improved, for example, by adding or removing microservices or changing the flow of events. Additionally, it helps to structure teams that manage particular microservices accordingly, as during the process, we aggregate related events together.

Advantages of Event Storming

Event Storming sessions can bring multiple benefits to the organization. The key advantages of applying this technique would be the following:

• Improves Team Alignment: By bringing together cross-functional teams, Event Storming ensures that everyone is on the same page and aligned on the business rules and processes.
• Increases Understanding: The visual representation of the business processes helps teams understand the system more deeply and uncover more valuable insights.
• Uncovers Hidden Requirements: By breaking down the business processes into smaller events, Event Storming can uncover hidden requirements that were not previously considered.
• Increases Collaboration: By encouraging collaboration and discussion in the same room, Event Storming fosters a more collaborative environment and helps domain experts, business decision-makers, product owners, designers, and software developers work together more effectively.
• Enhances Communication: Discussion on domain events forces a common language for teams to communicate about the business terms and processes, which can help to reduce misunderstandings and improve the overall quality of communication during the development process.
• Provides a Historical Record: The output of an Event Storming workshop can be used as a historical record of the team’s understanding of the business processes, which can be helpful for future reference.
• Improves the Design of Systems: Event Storming can help teams design better systems by identifying the most important events and flows and ensuring that they are handled correctly.

Take a Deep-Dive Into Event Storming With nexocode Facilitators

In conclusion, Event Storming is a powerful workshop methodology that can help teams gain a deeper understanding of complex business domains, map user flows that drive software systems, and unlock opportunities for optimization. By using simple sticky notes and discussion, teams can identify and visualize important parts of the domain model, making it an effective tool for product development, data strategy, and microservices architecture.

Event Storming workshops are a great way to align teams on business rules, gain a common understanding of the domain, and create a shared language that can be used to drive development. If you’re interested in attending an Event Storming workshop or have questions about how it can benefit your team, feel free to contact our experts at nexocode. We have a deep understanding of this methodology and have facilitated numerous successful workshops, helping organizations achieve their goals and improve their processes.