We have done a lot of great work so far. We have analysed our business domain from a big picture perspective, recorded events and created the first draft of subdomains. That's fine, but not enough to start coding.

It is time to move forward and tune our subdomains. How do we do this? The answer is Process Level Event Storming. This technique allows us to focus on concrete processes in our draft subdomains. Thanks to it, we may have discovered - and we certainly will - that our previous work does not reflect reality. After all, the devil is often in the detail, and a small detail can often turn everything upside down. Let's take a final look at the results of the Big Picture Event Storming workshop:

It clearly states that we have at least 5 subdomains to work on. We will focus on 2 of them as the analysis of others will be a repeatable work - thanks to it you can try to practice it on your own. The selection will cover:

• Offers
• Contracts

subdomains.

Before we start, I would like to introduce you to 4 new types of cards that we will be using:

Policy Card

• Color: Usually purple
• Description: Describes a decision rule or a business policy that dictates what action should be taken under certain circumstances. Policies are typically derived from business rules or legal requirements
• Purpose: Policies guide the decision-making process within the domain and often lead to the generation of commands based on certain conditions

Command Card

• Color: Usually blue
• Description: Represents an action taken by a user or system, which changes the state of the domain. It's usually a verb or a verb phrase, like Sign Contract or Cancel Subscription
• Purpose: Commands are crucial for understanding what actions can be performed in the system and what triggers these actions

Read Model Card

• Color: Usually green
• Description: Represents the data that is read or viewed by users or systems. Read Models are the way the system exposes information after processing events
• Purpose: They help in understanding how data is presented to users and what information is available for making decisions or performing actions

Actor Card

• Color: Usually yellow (small)
• Description: Represents a person or role that interacts with the domain. Actors can be the initiators of commands or recipients of information
• Purpose: 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

So this set of cards will allow us to show who interacts with the process, what data is given to the person interacting with it, who triggers commands that lead to events, and so on. After the Process Level Event Storming workshop, our diagram will look something like this:

There is a lot more detail compared to what we had before, especially in the Contracts subdomain.

During workshops you will see that some of your subdomains are very simple. There are no business rules, the processes are straightforward. This should tell you that it will probably be a very simple subdomain of either Supporting or Generic type. And in our example, Offers will be an example of one of these.

On the opposite, Contracts is a good candidate for a Core subdomain - already 3 policies, based on verification there will be one or the other action handled. During workshops we discovered way more processes than in Big Picture Event Storming. There is e.g. Customer Verification or Contract Rejection that has not been present before.

Ok, let's take a step back and define all the types of subdomains mentioned:

Core

• Description: The Core subdomain is the central part of your business that differentiates it from competitors. It is where the primary business value is created and is often the reason why customers choose your product or service over others
• Characteristics: This subdomain is unique to your business and requires internal development to meet specific business needs. It is complex, frequently evolving, and needs continuous refinement and innovation
• Focus: Highest priority in terms of resources and attention

Supporting

• Description: Supporting subdomains are necessary for the business but do not constitute its competitive advantage. They support the core ones but aren't the primary focus of the business
• Characteristics: Less complex than the core subdomain, these areas still require specific business logic but are not as critical for the unique selling proposition of the product or service
• Focus: Often developed in-house (can be as well outsourced), but with less focus compared to the core one

Generic

• Description: Generic subdomains are the standard functionalities that are common across many businesses and industries. They don't provide competitive advantage and are not specific to the business
• Characteristics: These are often standardised processes or features with well-established solutions in the market
• Focus: Businesses opt for off-the-shelf solutions

Before you decide which direction your subdomain might take, it's very important to talk to the business about their forecast of how often this subdomain will evolve. You should also look at historical data to see how often processes have changed in previous years. This will give you a more structured way of looking at potential variation. I can recommend the use of DDD Crew's Core Domain Charts, which will allow you to document such potential changes:

From the diagram you can see that the Reports module has both low complexity and low business differentiation, so there is a high chance that you will find an off-the-shelf solution that you can buy. On the other hand, there are Contracts that have high complexity and above average business differentiation. This means that you are likely to have to build them yourself. There are also Offers and Passes that fall into the Supporting type of subdomain, but both have the potential to change their nature in the near future:

• Offers may become more complex due to the increased number of policies or regulations that may come into play. As these will be based on your custom, internal rules, it will be more differentiating from business perspective (you will not find off-the-shelf solution for it and additionally you might want to keep the knowledge about it inside your company instead of outsourcing it)
• Passes today are not so complex (they still have some business rules) that they could become a generic solution that can be used by your and other companies. Not today, but in a few months there may be a player who will sell it as a ready-to-integrate (off-the-shelf) solution

This way, you can create a kind of map to document your way of thinking and your strategy for building software.

There is one other thing I would like to mention. Sometimes there will be a situation (especially in large companies) where during the workshop you will notice that one of the subdomains is too big. Usually this feeling is correct and this subdomain should be the subject of further investigation. Often it turns out that this subdomain is another business domain that contains other subdomains:

At first glance, everything looks normal, but it turns out that in the subdomain of Pharmaceuticals there are many processes, often not connected to each other in any way. After further investigation it looks as follow:

Single subdomain has grown up to become another business domain with its subdomains:

• Drug Research
• Regulatory Affairs
• Sales

In such a situation, the subdomain of Pharmaceuticals should be the subject of a completely separate business case (starting from scratch), handled in separate workshops (often by a completely different team).

Okay. Now that we have fine-tuned our subdomains, we are ready for one of the final steps in strategic Domain-Driven Design. It is called Bounded Contexts and is described in the next chapter.

FREE Case Study: How did I introduce Domain-Driven Design in large scale organisation? Book an appointment with me to know more!