We use clues (heuristics) that help us to discover subdomains:

• organization structure – departments, teams and positions

I think everything is clear. The organization has many departments organized as tree. Departments may have multiple divisions. Sometimes the divisions are not clear at first glance but looking at the positions gives you more information. The outcome is:

It is also worth mentioning that employees are organized into teams. Teams are created for specific goals/tasks that implement some organizational processes. So, the team may point to a subdomain.

• roles and responsibilities of employees

Most often, employees work in specific departments of the company and deal with everything in this area. Stanisław from the warehouse does everything to make the warehouse work properly. Of course, there are many people in the department, but all of them are responsible for the whole area.

But, in one department, especially in large organisations, employees can have different roles and responsibilities. They deal with various areas, e.g. individual and corporate invoice management. This may indicate that the processes for individual and corporate customers are different. If so, we have two subdomains, and if not, we stay with one.

In small companies, usually, there are no departments, and one person may have many roles and responsibilities, e.g. Patrick is responsible for IT software, IT hardware and licenses, and Emily is responsible for accounting and HR.

We must pay attention to what roles and responsibilities employees perform. These roles and responsibilities probably define the subdomains.

• the language of employees/domain experts

The same thing, i.e. a product, is perceived differently by different employees/domain experts. This is a strong indication that they are responsible for distinct processes. Most often they work in distinct departments, teams or have disparate roles/responsibilities:

In different contexts, a ‘product’ has different properties and behaviour (what can we do with that product). We call it model because it reflects only important aspects of product in particular context:

In real conversations, employees/domain experts are unlikely to use the name “product” but synonyms that are more appropriate for them in the context of what they do. Expert from warehouse use the name “commodity” or “package”, expert from advertising “advert/ad”.

We need to catch these synonyms. Synonyms denote different contexts and thus domains.

• (sub)domain names

Domains often end in “-ing” or “-tion”, nouns made from verbs – express some purpose, actions?

There are many processes, actions and interactions inside the (sub)domain, so it makes sense to express (sub)domain name as a gerund/verbal noun.

• systems we integrate or communicate with

Integration with system/application may point to subdomain. Example: integration with the payment system. In one system we have a simple flow, only transferring payments to an external system. In this case, it makes no sense to separate the payment domain. In another system, we have several payment methods, different business rules, handling failed payments, etc. In this case, it is worth separating the payment domain.

• high level process steps

The process steps naturally designate the subdomains. The customer of an online store experiences steps in the purchasing process: he searches for a product, adds to the basket and confirms the order, makes a payment, and waits for delivery.

• big picture – event storming

Big picture of event storming is used to reflect or design as the name suggest big picture how organisation works. We model/reflect the main processes in the organization. The main processes (or parts of them) indicate the subdomains. Event storming is great because you have processes presented on a large wall – you can see this, and you can easily mark subdomains.

(todo: add some picture)

• business value

By defining the business value we discover/define the most valuable subdomains for a company.

Which clues(heuristics) to use?

Simple answer – if possible, all of them. The more the better, because you must be sure that the (sub) domains have been correctly identified.