Introduction
This blog post will examine domain events, what they are, how they are identified during event storming, and their impact on domain modeling.
Domain model and domain events
When working on complex software, we want a rich and precise model representing the real-world domain as closely as possible. This model tends to change over time as our understanding of the domain increases. Each insight can potentially lead to major refactoring of our model, which is good. Usually, we start with entities like accounts, invoices, and customers. In my experience, this leads to the dreaded entities as microservice antipatterns, making transactions and loose coupling between applications difficult.
Domain events are significant occurrences within a business domain. They represent meaningful actions or decisions that have happened in the past and are crucial for understanding the flow and behavior of the overall system. One example is an invoice sent. Domain events can be interesting for other applications or systems. For my definition of application and system, please see the Service-Oriented Architecture Framework.
Focusing on domain events, which do not change nearly as much as our model, we introduce constraints that, quite early on, give us insight into the domain and subdomains and limit the number of potential domain model representations. Domain events are more closely anchored in the real world than our model representation. By mapping domain events on a timeline and clustering related ones together, we start to get a domain overview.
Event Storming is an innovative workshop-based approach designed and created by Alberto Brandolini to help teams quickly explore and understand complex business domains by identifying these domain events.
Event storming
Types of event storming
There are 3 main types of event storming:
- Big picture
- Process modeling
- Software design
Big picture
Big-picture event storming involves exploring the problem space from a high-level perspective. It typically includes stakeholders like CEOs, founders, CTOs, and HR to envision the overall experience and identify key events. This type helps define events, place them on a timeline, identify actors and systems, and spot hot spots and opportunities for improvement. As the name suggests, we should not limit the type of events here; bring all the events the stakeholders can think of.
- Use orange sticky notes, write events in the past tens on them, and place them according to a timeline spanning from left to right.
- Use red sticky notes to identify hot spots—areas with many events clustered together. These areas might indicate bottlenecks or complex interactions and are subject to discussion and clarification.
- Use sticky pink notes to identify external systems. These are placed above the events.
The idea of the big picture is to not constrain ourselves too much and instead see the entire context. Alberto sees cross-department appreciations as a result of the overall business insights. Domain events typically cross bounded contexts. Big-picture event storming is a good starter choice.
This is a made-up example, so please take it as such.
Process modeling
Process modeling event storming focuses on understanding and mapping out specific business processes in detail. Typically, we take one of the hotspots found in the big-picture event storming session. It involves identifying all the events within a particular process, such as placing an order. This type of event storming helps teams visualize the entire process, identify dependencies, and uncover potential bottlenecks or areas for optimization.
The grammar is somewhat more complicated with the additional building blocks:
- Use blue sticky notes for commands; decisions taken by a user or a piece of software
- Use Lilac sticky notes for policies, which describe how a system is supposed to react to given events. These are the building blocks that trigger new commands after certain events.
- Use green for read models; these are input and output data
Alberto makes a point of forcing people to identify these lilac sticky notes. Additionally, he mentions that the big picture is for discovery where disagreements are OK, whereas process modeling is where we meet those difficult consensus agreements.
We now have the following grammar:
Following the made-up shipping example, we can model the specific order placement process:
Software design
Software design event storming focuses on the technical aspects of the system. It involves grouping related events and commands around aggregates, which are clusters of related domain objects. This type helps define the software components' structure and behavior, ensuring they align with the identified domain events and business processes.
Software design is a continuation of process modeling, but we focus on identifying aggregates in a system and their domain events. Thus, we extend the grammar with:
- Use yellow sticky notes for aggregates
Giving us the total grammar:
Following up with our made-up example:
Facilitating event storming
Event storming sessions should ideally be executed in the real world. While there are benefits to doing them virtually, many of the participant interactions and discussions are hindered.
Conclusion
Event Storming is a workshop-based approach developed by Alberto Brandolini to help teams understand complex business domains by identifying domain events. It involves three main types: Big Picture, Process Modeling, and Software Design. Big Picture focuses on high-level exploration with stakeholders to identify key events and opportunities. Process Modeling delves into specific business processes to uncover dependencies and bottlenecks. Software Design aligns technical aspects with domain events and aggregates. The approach emphasizes real-world interactions and provides a structured method for domain modeling, reducing unknowns and setting boundaries on solution space.