#50 DDD Series: Fine Tune Event Storming Results

After our initial exploration and identifying business events in our fitness domain, it is time to dig deeper and uncover the connecting elements: actors, commands, policies and read models.

We have done much great work so far. In the previous post, we have analyzed our business domain from a big-picture perspective, recorded events, wrapped them into processes, and grouped them.

That's fine, but not enough to start technical implementation.

We still need to examine our business processes at a deeper level. Luckily, Event Storming comes with a solution called Process-Level analysis. At this level, we will focus on details—actors, commands, policies, and read models. Ultimately, we should have a clear map of our business processes, ready for a technical design.

Before we start, I would like to introduce you to four new types of notes:

Command: It is usually pictured with a blue card. Represents an action taken by a user or system that changes the state of the domain. It is usually a verb or a verb phrase, like Prepare contract or Publish offer. Commands are crucial for understanding what actions can be performed in the system and what triggers these actions.

When you are adding commands, try to avoid having both a command and an event that basically say the same thing. Look at Process payment command and Payment processed event - they are just repeating each other!

Instead, you could have something like Validate payment details and authorize transaction as your command, which then leads to the Payment processed event. This cuts out the redundancy while still capturing what is happening.

Policy: It is usually pictured with a purple card. Represents a business policy that dictates what action should be taken under certain circumstances. Policies are typically derived from business rules or legal requirements. They guide the decision-making process within the domain and often lead to the generation of commands based on certain conditions.

Read model: It is usually pictured with a green card. Represents the result of a translation of a business event. It is the data a user or system needs to execute the action. Read models could still be a little bit vague, so treat them as a draft.

Actor: It is usually pictured with a yellow card. Represents a person or role interacting with the domain. Actors can be the initiators of commands or recipients of information. Actors help identify who or what is interacting with the system, providing insights into user roles or other entities that play a part in the domain.

Let's first check out how we handle offers. After digging deeper into this area, we have spotted some interesting things:

We have three actors:

• Sales representative who prepares the offer.

• Manager who provides feedback to the prepared offer.

• Marketing specialist who releases offer to the market.

who need to work together before an offer goes live. We also noticed something we missed in the Big Picture sessions - the offer approval process.

There are two policies:

• Revision handling policy which establishes how many revision cycles are permitted and timeframes for implementing changes.

• Offer publication standards policy which sets requirements for formatting, branding, and content that must be met before an offer can be published.

One more thing that came up was the Inquiry sent for an offer event - someone in the group started a discussion about whether this should be part of Offer Management at all. We couldn't reach a decision on this, so we tagged it as a hot spot to come back to later.

Next, we move to contract processing. This time we also discovered additional process that we missed during initial workshops.

Next, we move to contract processing. This time we also discovered an additional process - the compliance verification at the end was something we completely missed in earlier sessions.

We have four actors:

• Legal officer who drafts contract terms and conditions

• Sales representative who customizes contracts for specific customers

• Customer who reviews and signs the contract

• Compliance officer who ensures contract meets regulatory requirements

who need to work together for a contract to be fully processed. We noticed that the sales rep specifically handles customizing contracts for two types of customers: MVPs and renewals.

There are two policies:

• Customer classification policy which includes guidelines for identifying and handling MVPs and renewals, including special terms or expedited processing.

• Regulatory compliance policy that defines specific requirements that must be verified by compliance officers before finalizing contracts.

Next, we move to pass lifecycle management. This time we have added more detail to the flow based on our deeper understanding.

There are two actors: a manager who enrolls all passes in our system, and a security officer who initiates pass termination. We also find other events like Time elapsed and Security breach recorded. Additionally, we decided to replace Pass expired with Pass validity ended to be more clear.

There are two policies:

• Pass expiration policy which determines when and how passes should expire. It contains the business rules that define the conditions under which a pass is considered to have reached the end of its validity period.

• Pass cancellation policy which defines the circumstances under which passes should be cancelled for various reasons, the protocol to follow, and who has the authority to make such decisions.

Summary

As you can see, thanks to Process Level we are able to spot details that were missed during initial sessions. Our exploration of offer management, contract processing, and pass lifecycle revealed various important insights:

1. We identified key actors in each process and their specific roles:

2. We discovered missed processes:

   • The offer approval process in the offer management

   • The compliance verification step in contract processing

   • The security breach handling in the pass lifecycle

3. We properly structured our model by:

   • Avoiding command/event duplication

   • Adding policies between events and commands

   • Improving terminology for clarity

4. We identified important policies like:

   • Offer publication standards

   • Customer classification policy

   • Pass expiration policy

   • Pass cancellation policy

It helped us understand how actors cooperate through specific commands and events, giving us a much richer picture of our domain.

In the next post we will focus on describing subdomains based on what we modelled till now. Till then!