Hands-on DDD featuring Event Storming, CQRS, Event Sourcing in .NET — Part 1 Event Storming🏢✈️🚀
Welcome to a blog series providing an end-to-end example of Domain-Driven Design, demonstrating all phases with .NET examples. For a deeper understanding of specific terms, please refer to my blogs linked below.
Before we delve into each concept, let us define the business we are using for designing system using DDD. Best Place For Rent, Inc. (BPFR) is the largest developer, owner and manager of rental apartments across US and they have number of properties across different states. Each state is using different software’s for renting and leasing apartments, and they decided to build a software to streamline the process used across properties where the system should scale, and the company grows. This is where we were hired to build the software for BPFR.
Historically, understanding business systems involved mapping processes through technical modeling or costly trial-and-error coding. While these methods are valuable, their technical complexity often excludes many domain experts from the discussion.
This problem is solved by event storming. Event storming simplifies the approach, fostering a deeper understanding and increased productivity by involving multiple stakeholders at various levels of the business. Utilizing sticky notes and a collaborative group, you can efficiently and enjoyably unveil your business processes.
In this blog, we’ll explore the process of conducting your own event storming workshop. It’s essential to note that this exercise is designed to enhance the understanding of the concept and may not address every use case within a company. Below is the end state we will achieve after as we go through the blog.
What is Event Storming?
Event storming is a rapid group modeling approach within domain-driven design, introduced by Alberto Brandolini in 2012. Serving as a swift alternative to detailed UML diagramming, event storming is a collaborative workshop technique that assembles project stakeholders, including both developers and non-technical users, to delve into intricate business domains. It’s crucial to note that event storming does not replace UML diagrams, design documents, deployment plans, or other implementation models. Instead, it complements and expedites the development process by gathering relevant stakeholders to swiftly model the broader business domain and its processes.
Advantages of Event Storming
Event storming is designed to be both efficient and enjoyable, offering several advantages when key practitioners come together, whether physically or virtually:
- Fast: The event storming approach significantly reduces the time required to create a comprehensive business domain model. What used to take weeks can now be accomplished in a single workshop lasting a few hours.
- Straightforward: Unlike complex UML, event storming simplifies the process into terms that are easily understandable by both technical and non-technical stakeholders.
- Engaging: Event storming aims to make modeling an interactive and enjoyable experience. By fostering a hands-on approach, every participant is encouraged to actively contribute. This not only enhances the enjoyment of the process but also leads to more valuable insights as participants readily engage, offering suggestions and expertise.
- Effective: Distinct from data modeling, event storming results in a fully behavioral model that can be rapidly implemented and validated. For optimal results, teams should integrate event storming with an implementation strategy aligned with domain-driven design.
The primary value of event storming lies in the meaningful conversations it stimulates. The insights gained from the workshop can be employed in subsequent modeling processes for software development. Alternatively, organizations can leverage event storming to enhance their understanding of business processes, enabling more informed decision-making moving forward.
Steps in Event Storming
Event storming has undergone evolution, presenting various iterations and approaches to suit different preferences. The foundational steps outlined below constitute the original structure of an event storming workshop. Nonetheless, feel free to tailor the process to align with your specific requirements and objectives.
Step 1: Invite the right people
Who qualifies as the right people? They are individuals equipped with the expertise to pose right questions and possess the corresponding answers. This assembly typically comprises a diverse blend of stakeholders, encompassing representatives from user experience, business, architecture, development, and IT.
Step 2: Decide the modeling space
It is up to each of people running the session to decide how they want to do this. Traditionally, they used to do this on big wall with sticky notes. Some organizations use tools like lucid chart etc., for running these sessions. We will use lucid chart for rest of the process.
Step 3: Understand the business domain
Collaboratively, the team delves into the intricacies of the business domain to reveal an all-encompassing process. The event storming model encompasses three primary elements: domain events, commands, and aggregates.
Identify domain events
The initial phase involves the identification of events, which are occurrences within a process or system. Significant events instigate responses, aiding in comprehending the system’s functioning and rationale. It’s essential to note that events are always recorded in the past tense.
To represent an event on the timeline, employ an orange sticky note (or the agreed-upon color code). As your team introduces events onto the canvas, begin arranging them in a chronological order over time. In our case below are the events the group has come up with.
Note: There will be more events in a rental property but just taking some of them for demonstrating event storming.
Connect domain events to commands
Having identified the events, the next step involves assessing each event to understand its origins and outcomes. Essentially, you need to inquire about what initiated this event — whether it was users, other events, or external systems.
The trigger or origin of the event is documented as a command. Commands are conventionally recorded on blue sticky notes in the present tense and commonly depict user interactions with the system (e.g., “Submit an application “). However, your team has the flexibility to document commands to encompass both user and system actions.
Connect events to reactions
The complementary aspect of the event process involves the outcomes or actions that follow the event, known as reactions. Reactions encompass the essential actions or results triggered by an event and are documented in the present tense. For instance, a process flow describing the event-reaction relationship might state, “When a new account is created, we will send a confirmation email.”
By integrating commands, reactions, and events, you can effectively map out the comprehensive cause-and-effect processes within the system.
Step 4: Define the domains using bounded contexts
For high-level event storming, the process may conclude once your team has incorporated domain events, commands, and reactions. Nevertheless, event storming can seamlessly integrate with the domain-driven design technique to outline your system’s structure and set your team on the path to implementation.
In essence, you can initiate the organization of modules using a concept known as bounded contexts. Enclose the related modules within a box or circle — or, in Lucid chart, employ containers — and provide them with labels.
Subsequently, employ arrows to commence context mapping, indicating how the modules within a bounded context interact with other contexts. For instance, you might have grouped together commands, reactions, and events related to payment. The payment context is connected to the resident management context because, upon processing a payment, the system needs to trigger a command to block an apartment.
Step 5: Define aggregates with in a bounded context
In the image above, each of the dotted areas represents a bounded context, and we can subdivide them into aggregates, such as Lease and Customer within the leasing bounded context. It’s important to note that similar types of aggregates may also be found in other bounded contexts.
In this blog we have seen how to perform event storming and define bounded contexts for our real estate company. In future blogs we will take a context and implement using CQRS and Event Sourcing.
For rest of the blogs in this series please see below links.
🙏Thanks for taking the time to read the article. If you found it helpful and would like to show support, please consider:
- 👏👏👏👏👏👏Clap for the story and bookmark for future reference
- Follow me on Chaitanya (Chey) Penmetsa for more content
- Stay connected on LinkedIn.
Wishing you a happy learning journey 📈, and I look forward to sharing new articles with you soon.
