After all the previous steps, we are ready to continue our journey and try to prepare the first draft for splitting the Fitness Studio domain into several subdomains. But there is still a long way to go.

First, let's try to define what a subdomain is.

Every business operates in some business domain - we all know that. To keep it efficient, it is usually divided into different areas such as warehousing, deliveries, accounting and so on. In addition, there are many different processes within each business unit or - in larger companies - department. It is through these processes that the business can serve its customers and generate revenue.

Let's look at an example business domain that I mentioned in the previous part of the DDD series - a healthcare organisation. This can include areas such as patient management, scheduling, medical records, prescription management, etc. Let's assume that each of these can be treated as a subdomain.

Can patient management and scheduling be part of the same department? Yes, of course they can! Can part of patient management be part of more than one department? Yes, it can. This is why saying that a subdomain is equal to a department is wrong and will bring you many problems in the future.

Let's consider another practical example to further illustrate the concept of subdomains in Domain-Driven Design.

Imagine you are building an online marketplace, similar to e.g. Amazon. Within this marketplace, there are several distinct areas of functionality, each serving a specific purpose:

• Product Catalog Subdomain: this subdomain manages everything related to products: adding new products, updating product information, and categorising products into different sections (e.g., electronics, clothing, books)
• Order Management Subdomain: the order management subdomain handles activities related to customer orders: placing orders, tracking orders etc.
• Review and Rating Subdomain: here users can leave reviews and ratings for products they have purchased, helping others make informed decisions

Each of these areas represents a subdomain in the context of the online marketplace application. By defining these subdomains, developers can focus on the specific complexities and rules within each area without getting overwhelmed by the entire system. This approach allows for clearer communication among team members and ensures that each part of the application is developed and maintained effectively.

There is another very important thing to remember. Sometimes a subdomain can represent another domain and contain many other subdomains - this can happen in large companies. So when you are modelling a domain and running the workshops where you are going to break it down, you may find that one or more subdomains are too big to fit into one system and you need another. To illustrate this, let's look at the image below:

The example on the left is simple. We have split the Healthcare domain into 4 subdomains, none of which are complex enough to split into other subdomains. The example on the right represents a large environment of educational institutions, where each subdomain can be as complex as Human Resources, which is then split into its own subdomains. This is a perfect example of how a subdomain can become a domain.

Ok, great. Now you know, what a subdomain is (if it is still unclear, please let me know!). But how to find these subdomains?

That's where modelling techniques come in. There are many of them - some older, some quite new. My 2 favourites are:

• Event Storming
• Domain Storytelling

But you might use as well other techniques like Story Mapping, Impact Mapping, Story Storming or anything else. I would like to focus on one method and show you the path from the beginning till the end of strategic DDD.

Let's go with Event Storming.

I am going to scratch the surface of it without detailed explanation. If you want to see how does it work in details, IMO there is no better source than following resources.

Officially, Event Storming is divided into 3 levels:

• Big Picture
• Process
• Design

but I fell in love with another level proposed by Radek Maziarka - Bounded Context. In this series, we will focus on 3 of them:

• Big Picture
• Process
• Bounded Context

Each will be part of a different focus area. When we talk about creating subdomains, we need to start at the big picture level.

How do you organise such a brainstorming workshop? I usually try to invite people who are decision makers and domain experts. Sometimes these are business people, sometimes developers (who - in legacy systems - usually have the most knowledge of the business processes), or a mix of both. I prefer sessions with less than 10 people (including me as the facilitator). On-site or remote? Both are possible. If you go on-site, you will need orange cards (instead of sticky get static ones - you can easily move them around), markers and a long wall to stick the cards on. If you decide to run the workshop remotely, you can use software like Miro (in my opinion, there is no better option for remote Event Storming sessions). Try to split the workshop into several parts - we usually decide to have a short break after each hour of the workshop.

There are 2 types of notes that we usually use.

Events:

This is the main type that will represent all the business events that can occur in our domain. The rule of thumb is to name it in the past tense (something happened) because it is an event that has already happened.

And Hot Spots:

which are questions and inputs that cannot be answered during the workshop (there is no knowledge about it) or which we want to shift.

It is time now to start the workshop around our Fitness Studio domain. Every participant gets as many orange notes as he/she needs and start stickying business events around. At that point in time there is no focus on any timeline and there are no good or bad notes. After some time, your wall will look similar to this:

As you can see there are both:

• Events that are related to business e.g. Contract signed or Pass expired
• Events that are related to technical things e.g. Request sent to Offer API or Button clicked

Remove the technical ones as they are not important in the context of business and subdomain distillation. Note: there might be duplicated events, so just throw away all duplicates.

After cleanup, your whiteboard should look like this:

The time has come to group the various events. Try to group it based on:

• Similar wording, e.g. Offer with Offer, Pass with Pass etc. NOTE: Be careful - it is treacherous. Sometimes, Offer in one context can mean something else in another context
• Timeline - what has to happen before the next event occurs
• Actors - who is responsible for execution of the process
• End of process - to execute a process we need several events. If the next event does not fit to the process it might be an indicator that it can be a part of a separate subdomain

After marking it, we are ready to group it:

In theory, everything is fine. But I made a mistake. Look at the diagram again and try to find it before you read on. One of the events does not match the process.

We want to publish the offer to our potential customers. Several steps are required:

• Someone has to prepare it
• Then it has to be reviewed and corrected
• When it is ready it has to be published

Voila, our offer is published. So, what does Inquiry sent for an offer does here? This is the mistake.

I accidentally put it next to other offer events because it contained the well-known word - Offer. But there is another one - Inquiry, which did not appear before, and this event is the result of an action taken by a customer (another actor) in a completely different process, not by someone who prepared the offer (probably a salesman). Let's fix our diagram:

Now our events are grouped. This is our draft of subdomains. They may change in the future (e.g. during the Process Level Event Storming or when your domain changes), but it is a good scaffold to continue with. Now it is time to name them - remember to do this together with everyone in the workshop:

We are done for now. After heavy workshops we got it - we can continue to model the details of each process. Thanks to that, we will be able to rework our draft division and select types of subdomains - Core, Supporting and Generic.

Let's get down to work and tune our subdomains!

---

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