How we used Event Storming Meetings for enabling Software Domain-Driven Design
An experiential report of how we fostered Domain-Driven Design (DDD) into our software engineering process by leveraging Event Storming Meetings.
Domain-driven design (DDD) is a software development approach that focuses on modeling the business domains and rules of a system. It has been known as a powerful technique that can help developers build more effective, flexible, and maintainable software systems. However, people across communities and enterprises have a hard time trying to learn, master, and apply DDD concepts in practice. From careful observations and empirical experiences, this difficulty varies depending on some factors.
Firstly, DDD is a massive body of knowledge. The subject's original book “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans is often reviewed as an important and required reading, but it is also known to be very dense and complex to assimilate it all. In that context, acquiring a first grasp on the DDD fundamentals can often be challenging at the outset which delays the gratification of practical usage. In a human sense, that delay of gratitude will reduce engagement throughout the process, restricting the effective application of the technique. Moreover, it is important to acknowledge that team members possess different levels of experience and seniority, requiring additional efforts of knowledge equalization to ensure that everyone has sufficient background to actively participate in the DDD process.
Secondly, the complexity and size of the business domain that you are trying to model will also impact the difficulty of applying Domain-Driven Design. In the real world, business domains are frequently complicated and nebulous, with rules that can vary across numerous scenarios and be contingent upon diverse inputs. In that circumstances, you will need to spend more time studying the domain and working on the DDD modeling process.
Finally, the resources available to you can also impact the path to learning and practicing DDD. Many books, articles, and online courses cover the subject, and these can be very helpful. However, the quality and relevance of these resources can vary, so it’s important to select those that provide a comprehensive exposition of the fundamentals and guide you right toward the state of practice.
In light of these challenges, it becomes natural to start looking for additional tools that can alleviate DDD's learning curve and yet offer a practical usage of the framework. This is where Event Storming Meetings come into play. Such an approach conducts the process of creating the essential components required for DDD, enabling us to model and develop our new software services more efficiently and effectively from the beginning.
Before sharing our Event Storming experiences while building Inventa Shop, let’s first review some critical concepts. This will provide a solid understanding of the tool and an initial sense of how it can be used.
Event Storming for DDD Fundamentals
Created by Alberto Brandolini, Event Storming is a collaborative meeting technique for Domain-Driven Design. It enables cross-functional teams to rapidly explore and model complex business domains through workshop meetings. It is a visual and interactive process that encourages team members to collaborate and share their knowledge to uncover domain events and identify business rules.
- Workshop Meetings: these are meetings designed to be highly collaborative, with domain experts and technical participants from different areas of the organization (such as product management, software engineering, product design, quality assurance, data, etc.) working together to share knowledge and insights about a business domain that is expected to be developed into a software system. The workshop is facilitated by a moderator who helps keep the conversation focused and productive.
- Domain Events: these are the actions that are expected to happen within a business domain. In other words, they are all significant occurrences or changes within a domain that are of interest to the business stakeholders and are expected to be covered by your software application. These events can be things like a customer placing an order, a payment being processed, or a new product being added to an inventory. The main goal of an Event Storming meeting relies on identifying and uncovering the domain events.
- Commands: these are intentions or requests made by an external actor (such as a user or another system) that trigger an event in the business domain. For example, a user placing an order on an e-commerce website would be a command. That command can trigger an event or a series of events within a system to fulfill an order. Commands help us to understand the interactions between actors within the business domain.
By combining Events and Commands, we will be able to map the business rules of a domain. Once mapped out, they provide a solid understanding of the systematic processes necessary for implementing a consistent software system.
Visual and Interactive Process
Event Storming Meetings rely heavily on visual modeling techniques to help participants understand the business domain and its various components. The most common form of visualization is the “Event Storming Board”, which is essentially a large whiteboard or wall where participants can map out the various events and business rules that make up the domain.
Furthermore, Event Storming is an iterative process, which means that the initial workshop is just the beginning of the modeling process. After that, the responsible team can continue to refine and build on the model, adding more detail and complexity as needed.
Business Language
In DDD, the ubiquitous language is an important component that refers to a shared and consistent language used by all members of a business domain. The language is meant to discuss and describe the concepts and business processes that are relevant to a domain.
One side contribution of Event Storming is to create that ubiquitous language around the business domain. By identifying and defining domain events and business rules, the participants across the organization can create a common vocabulary that is understood by everyone involved.
Having covered these fundamentals, we can now delve into how we introduced Event Storming to map the domain events of Inventa's Shopping Cart business domain.
Event Storming The Shopping Cart Business Domain at Inventa Shop
After months of validating our product market fit using a Shopify Store, we decided to develop our own marketplace platform to enable a greater evolution of the company's business strategies and product development. In that scenario, we were challenged to develop new software services to attend base functionalities of Inventa's new marketplace such as shopping cart, checkout payments, and order creations.
Following an approach taken by many startups, we structure ourselves into multidisciplinary teams where each of them is accountable for some fundamental part of our product capabilities. This report centers on our approach to modeling the Shopping Cart Business Domain by leveraging DDD and Event Storming meetings. The Shopping Cart Domain primarily deals with enabling users to manipulate items in a cart and proceed to checkout for payment when they are ready.
In other to dissect the business rules out of that domain, we conducted a series of Event Storming meetings across the responsible team which included people from multiple disciplines such as product management, software engineering, data, and SDETs (Software Development Engineer in Test).
For our Event Storming meeting, we focused on defining the following components in the form of visual post-its:
- Command: represents the execution of an action
- Event: it’s the result of an action
- External System: sites, APIs, and other external platforms
- Policy: a process that needs to be called when something happens
- Aggregate: an entity holding the business rules for a command execution
- User: person or actor that participates in some process.
- Actors: all users that participate in any process.
At Inventa, our main marketplace actors are called Retailers. - Hotspot: possible problems and risks that we don't yet know to handle.
- Query Model / Information: any data that needs to be queried from a source
Setting up the Meeting
Our Event Storming meetings were scheduled to last for one hour, and we did not set a predetermined number of iterations. Instead, we evaluated whether another session was required at the end of each meeting, as we aimed for the process to be as iterative as necessary. Ultimately, in order to enable post-it notes in a digital format, we leveraged a Visual Collaboration Platform, which granted users the ability to generate new post-it cards limitlessly on a virtual board.
Identifying Domains Events as First Step
The first step of the meeting is to make people write down the post-its that represent the domain events. These domain events serve as the foundation of the process as they configure the central artifact to define business rules. Therefore, it's quite important to devote significant effort to this initial action.
In the next illustration, you can take a look at the domain events we mapped for the shopping cart scenario.
Defining the Actors and Commands that trigger Events
Once the domain events had been defined, the subsequent step involved retracing the potential actors and identifying the necessary commands that must be executed, so the events can actually happen. Knowing the events in the first place turns this phase all about reverse engineering.
In the next illustration, you can take a look at the actors and commands for the previous Shopping Cart Events. It is worth noting that we arrange the post-it notes in a manner that enables us to visualize a fluid sequence: actor, command, and event.
Mapping out Complexity through Policies
In business domains, things tend to be complex and additional actions must be taken to ensure that an event is accomplished as expected. Event Storming handles that complexity through Policy definition. During our meetings, we enhanced our modeling process by mapping out all policies that should be called when something happens (whether it be a command or event).
In the next illustration, you can take a look at a partial view of the Policies we mapped between commands and events, and in-between events. Additionally, notice that we define red post-its to represent Hotspots (possible problems and risks). As your modeling becomes increasingly complex, some issues are expected to have an immediate resolution. In such cases, we denoted these as hotspots throughout our DDD modeling.
Reorganizing the Modeling Components in a Timeline
After improving our models in the previous step, we arranged them in a series of timelines based on the perspective of the domain actor (e.g. Retailer users). This step-by-step, time-based view of the commands, policies and events allowed us to formulate the business rules that emerged from the Event Storming in a sequential manner. By doing so, we were able to visualize the actions and outcomes that our users should expect when using our shopping cart product.
The following illustration presents the timeline we created using our Event Storming process. This organized representation showcases the sequential actions that our users should take, the corresponding policies that should be triggered, and the resultant events that would occur.
Identifying Aggregates & Query Models and Drawing Business Flows
Once we got a sense of the business rules from the previous timeline, we iterated the Event Storming once again in order to add other incremental dimensions: aggregates, query models, and business flows.
Aggregates are the expected business entities that should encapsulate certain business rules and execute them in response to a command. In our shopping cart domain, we concluded that the rules were straightforward enough to be contained within a single Cart aggregate. However, we may reassess and divide it into more suitable entities if required.
The aggregate is only an initial representation of the entities to be handled in software and database. It will act as a starting point for the actual entity modeling in the next technical definition for your services.
Query models helped us understand the points between the modeling components needed to access data from a given source.
This was important to identify external data source dependencies that are out of the limits of the Shopping Management Domain.
Finally, Business Flows naturally emerge when we connected post-its elements, binding them together to represent a cohesive business process that follows proper commands and leads to expected outcomes within certain boundaries.
In the following illustration, we can see the bounded business flows enriched with Aggregates and Query Models.
Based on that perspective, we formulated the following table to describe the observed business flows from the Event Storming in simple written language.
Establishing the Bounded Contexts
From the business flow visualization, it became evident what boundaries and dependencies our Shopping Cart Domain should have. With this perspective in mind, it was natural to draft the bounded context for the Shopping Cart’s business context. With this information at hand, we could more precisely delimit responsibilities and properly define the capabilities required for the upcoming shopping cart service.
Final Thoughts
With the Event Storming outputs, the engineering team gained strong ownership of the context and a shared business language to delve deeper into the technical definitions. We were able to confidently design the data models and determine the appropriate software architecture to implement all the necessary business flows for our shopping cart experience.
Once the meetings were completed and the service was implemented, it became evident that there were several benefits to incorporating Event Storming into our software engineering process:
- Better Alignment: By aligning business rules for later software implementation, Event Storming promoted a better understanding of the requirements and needs of the domain. This alignment resulted in a more accurate and relevant solution with very few reworks, bugs, and easy data model increments.
- Simplified Complexity: Event Storming helped us simplify the complexity of the Shopping Cart Domain by breaking it down into smaller, manageable business components. This approach enabled the team to better identify and focus on the most important and impactful aspects of the domain, giving us a sense of incremental releases.
- Quick Feedback: Event Storming provided rapid feedback and iteration, enabling the engineering team quickly validate assumptions, identify gaps, and refine the domain model when needed.
- Collaborative Approach: Our Event Storming meetings involved stakeholders, including business experts and technical team members, to collaboratively analyze and model the domain. This approach fosters a shared understanding and ubiquitous language for the domain, resulting in a more cohesive and effective solution.
- Visual representation: The use of visual diagrams and models in Event Storming facilitated communication and comprehension of complex business processes and flows. This approach helped us to create effective representations in the RFC (Request for Comments) documents, which were subsequently validated by the engineering chapter.
Incorporating Event Storming meetings into our software engineering process was not a simple or effortless task. However, given the benefits we gained from this approach, we achieved very positive results. It enabled our team to deliver a well-designed service with fewer bugs and more sustainability over the long term.
If you want to know more about us, add me on LinkedIn or apply to one of our open positions! Let’s learn together!
