Domain-Driven Design and Event Storming: Shaping Microservice Boundaries

In the world of software development, building scalable and maintainable applications is a constant challenge. One approach that has gained significant popularity is Domain-Driven Design (DDD), which emphasizes aligning the software design with the business domain. When it comes to breaking down monolithic applications into microservices, a powerful technique called Event Storming can be used to define the boundaries effectively. In this article, we will explore how Event Storming can be utilized to draw boundaries for microservices, along with my experience of carrying out an Event Storming exercise. Additionally, we will discuss the advantages and challenges associated with this process.

Understanding Domain-Driven Design and Microservices:

Domain-Driven Design is a software development approach that focuses on building applications around a well-defined domain model. By modeling the business domain in software, DDD aims to improve collaboration between technical and domain experts, leading to more maintainable and scalable applications. Microservices, on the other hand, involve breaking down large monolithic applications into smaller, loosely coupled services, each serving a specific business capability. This decomposition enables teams to independently develop, deploy, and scale services, promoting agility and scalability.

Drawing Microservice Boundaries with Event Storming:

Event Storming is a collaborative workshop technique used to gain a deeper understanding of complex business domains and model them effectively. Invented by Alberto Brandolini. It involves bringing together various stakeholders, including domain experts, developers, and business analysts, to explore the domain through a series of events and reactions. By capturing domain events and their interactions, Event Storming helps identify the contexts, boundaries, and responsibilities of different services within a microservice architecture.

My Experience with Event Storming:

Within our team, we undertook an Event Storming exercise a few months ago to explore a new business domain and see how we can use that to create microservices. The process involved the following steps:

1. Initial Setup: We used?Lucidchart?to provide unlimited whiteboard space to the team. It was great for working with remote teams. We pre-marked different colored notes for each step. For example, we used orange for Domain Events, green for Definitions, purple for Risks, and blue for Commands.
2. Assembling the Team: We brought together a diverse group of stakeholders, including domain experts, developers, testers, and product owners. Having a variety of perspectives enriched the discussions and ensured a comprehensive understanding of the domain.
3. Plotting Events, Definitions & Commands: First, we listed key events that occur within the system. These events represent significant state changes or triggers within the domain. Examples of events could include “OrderCreated,” or “Order Deleted”. Next, we plotted definitions and concerns. For example, an Order is an intention to buy or sell whereas a Trade is a result set of an order getting executed. We then highlighted the risks and concerns such as missing details about an API. After that, we plotted Commands which are paired with domain events to encourage further understanding.
4. Plotting External Systems & Time-Triggered Events: Then we plotted external systems such as pricing service that provides the quotes for a security. We also looked at time-triggered events. For example, we want to run a notification process every 10 minutes to send emails.
5. Plotting Policies & Read-Models: Then we plotted policies. These are reactive logic to an event. They sit between event and a command. For example, when your order value exceeds certain threshold, you want to route the order for a supervisor approval. Then we plotted read models which give us the data to help users carry out the commands. For example, if you want to update an order, we need the original order details. It could come from the screen or SQL or any other data source.
6. Plotting Aggregates and Bounded Contexts: By grouping commands and events together, we identified aggregates which are cohesive clusters of domain objects. Each aggregate represents a business concept with its own invariants and consistency rules. Aggregates often serve as natural boundaries for microservices. The end output of this would be more like Orders, Users, Accounts etc.
7. Defining Boundaries: We delineated bounded contexts which are self-contained domains within the larger system. Each bounded context corresponds to a microservice responsible for a specific business capability. Clearly defining these boundaries helps teams work independently and autonomously. When required we decomposed for performance and consolidated for transaction boundaries.
8. Aligning with Business Goals: Throughout the process, we regularly validated our microservice boundaries with the domain experts and ensured that they aligned with the organization’s business goals and needs.

Pros and Challenges of Event Storming for Microservice Boundaries:

Event Storming offers several advantages when defining microservice boundaries:

1. Enhanced Collaboration: Event Storming brings together cross-functional teams and fosters collaboration among stakeholders. It encourages open discussions, helps identify knowledge gaps, and promotes shared understanding of the domain.
2. Emergent Design: By visualizing event flows and interactions, Event Storming facilitates the discovery of bounded contexts and aggregates. It allows for an emergent design approach, enabling teams to iteratively refine their microservice boundaries based on domain insights.
3. Reduced Coupling: Properly defined boundaries lead to reduced coupling between microservices. Services become more focused on specific business capabilities, enabling independent development, deployment, and scaling.

However, Event Storming for microservice boundaries also presents some challenges:

1. Complexity Management: Mapping a complex domain can be overwhelming. Teams need to balance the level of detail captured during the event storming exercise to maintain clarity without becoming excessively granular.
2. Domain Expert Availability: Ensuring the presence of domain experts throughout the Event Storming exercise can be challenging. Scheduling conflicts or limited availability may impact the accuracy of the domain insights captured.
3. Technological Constraints: Event Storming focuses on the domain and doesn't explicitly consider technological constraints. Teams need to subsequently analyze the technical implications of the defined boundaries and ensure they align with the chosen technology stack.

To Conclude, Domain-Driven Design and Event Storming provide valuable techniques for designing microservices that align with the business domain. By conducting an Event Storming exercise, our team successfully identified and defined the boundaries of microservices, allowing for independent development and scalability. While there are challenges associated with Event Storming, the benefits of improved collaboration, emergent design, and reduced coupling make it a powerful tool for shaping microservice architectures. With careful consideration and active participation from domain experts, organizations can leverage Event Storming to create scalable, maintainable, and business-aligned microservice architectures.

References:

• https://www.eventstorming.com/#styles
• https://en.wikipedia.org/wiki/Event_storming
• https://www.lucidchart.com/blog/ddd-event-storming#:~:text=Event%20storming%20is%20a%20rapid%20group%20modeling%20approach,and%20non-technical%20users%29%20to%20explore%20complex%20business%20domains.
• https://app.pluralsight.com/library/courses/dotnet-microservices-scoping-organizing/description
• https://www.youtube.com/watch?v=a0lWpjlSRA0&t=904s&ab_channel=SelleoSoftwareOutsourcing
• https://www.youtube.com/watch?v=1i6QYvYhlYQ&ab_channel=ExploreDDD
• https://domaindrivendesign.org/ddd-domain-driven-design/