02 Domains, Subdomains, Core Domains, Generic Domains and Supporting Domains - A Confused Separation #

Hello, I’m Ouchuangxin.

The knowledge system of Domain-Driven Design (DDD) introduces many terms, such as Domain, Subdomain, Core Domain, Generic Domain, Supporting Domain, Bounded Context, Aggregates, Aggregate Roots, Entities, Value Objects, and so on. These terms are all key concepts, but they can be somewhat confusing, which may discourage you from practicing DDD before even getting started. Therefore, in this foundational guide, I hope to help you prepare for practice.

In addition, I want to mention that these terms may not all be applicable to your microservice design and development process. However, they can help you understand the core design principles and concepts of DDD. Furthermore, these principles and concepts can be valuable resources for IT strategy design, business modeling, and microservice design.

So, starting from this lesson, I will explain these key DDD concepts and help you thoroughly understand their relationship and roles in microservice design. Today, we will focus on understanding important concepts such as Domain, Subdomain, Core Domain, Generic Domain, and Supporting Domain in DDD.

Understanding Domain and Subdomain #

Let’s first take a look at the definition of “领域” (domain) in a Chinese dictionary: “领域 refers to the scope, category, or department of a specialized activity or industry.” According to Baidu Baike, “领域 specifically refers to a particular scope or area.”

Both definitions have one common point - scope. That’s right! A domain is used to define a scope, which means defining boundaries. This is why Domain-Driven Design (DDD) continuously emphasizes the importance of boundaries in its design.

When researching and solving business problems, DDD divides the business domain into subdomains according to certain rules. Once the domain is divided to a certain degree, DDD narrows down the problem scope within specific boundaries and establishes a domain model within these boundaries. The domain model is then implemented with code to solve the corresponding business problems. In short, the domain in DDD refers to the business problem domain that needs to be addressed within these boundaries.

Since a domain is used to define the business boundaries and scope, it can be of different sizes. The larger the domain, the wider the scope of the business, and vice versa.

A domain can be further divided into subdomains. We refer to the multiple divided subdomains as subdomains, each corresponding to a smaller problem domain or a smaller business scope.

As we know, DDD is an approach to handling highly complex domains, aiming to separate the complexity of technical implementation. So how does DDD make the business domain simpler, easier to understand, and implement from a technical perspective when facing complicated business domains?

It’s actually quite simple to understand. The research approach in DDD is similar to the research approach in natural sciences. When dealing with complex problems in natural science research, the usual practice is to divide the problems step by step. Then, for each divided problem domain, conduct in-depth research one by one, exploring and establishing the knowledge system of each subdomain. When all the problem subdomains have been studied, we have established a complete knowledge system for the entire domain.

Let’s take a look at the above image. This example illustrates how to establish a complete biological knowledge system for a peach tree. The study method is actually something we’ve learned in middle school biology classes. The research process is as follows:

Step 1: Identify the research object, which is a peach tree. Step 2: Subdivide the research object, dividing the peach tree into organs, and further subdividing the organs into nutrient organs and reproductive organs. The nutrient organs include roots, stems, and leaves, while the reproductive organs include flowers, fruits, and seeds. The knowledge system of the peach tree is the problem domain we have determined to study, corresponding to the domain of Domain-Driven Design (DDD). The organs such as roots, stems, leaves, flowers, fruits, and seeds are the subdivided problem subdomains. This process is the process of DDD dividing the domain into multiple subdomains.

Step 3: Subdivide the organs into tissues. For example, leaf organs can be subdivided into protective tissues, nutrient tissues, and conducting tissues. This process is the further division of subdomains into multiple subdomains in DDD.

Step 4: Subdivide the tissues into cells. Cells become the smallest unit of our research. The cell walls between cells determine the boundaries of the units and also determine the smallest boundary of the research.

Here, I will give a brief introduction to aggregation, aggregate roots, entities, and value objects. I will provide detailed explanations in Lesson 04 and Lesson 05.

We know that substances such as cell nuclei, mitochondria, and cell membranes together constitute a cell. These substances work together to give the cell specific biological functions. Here, you can understand cells as aggregates in DDD, and the substances inside the cell can be understood as aggregate roots, entities, and value objects within the aggregate. These entities work together within the aggregate to fulfill specific business functions. This process is similar to the process of determining functional elements and boundaries within a microservice in DDD design.

To summarize, each subdivided domain will have a knowledge system, which is the domain model of DDD. After completing the research in all subdomains, we have established a comprehensive knowledge system and domain model.

Above, we use the methods of natural science research to demonstrate that domains can be subdivided into subdomains to reduce research complexity. Now we will switch this topic to the business domain and compare and verify whether the subdivision process is consistent. Let’s take the insurance industry, which I am engaged in, as an example.

Insurance is a relatively large domain. In the past, insurance core systems used to implement all functions in one system, which is what we commonly call a monolithic system. Later, the monolithic system could no longer meet the development of insurance business, so insurance companies started the transformation to a platform architecture and introduced distributed microservice architecture to replace the original monolithic system. The distributed microservices architecture requires defining business domain boundaries, establishing domain models, and implementing microservices.

To achieve insurance domain modeling and microservice development, we can subdivide the insurance domain based on business relevance and process boundaries into subdomains such as underwriting, payments, reinsurance, and claims. The underwriting subdomain can be further divided into sub-subdomains such as insurance application, policy maintenance (life insurance), and policy endorsement (property insurance).

Within the insurance application context, a domain model for underwriting can be established, and this domain model will eventually be mapped to the system as an underwriting microservice. This is the process of subdividing an insurance domain and developing microservices.

Now you may say, “I am not in the insurance industry, how can I understand this process?” I believe that the business models of different industries may be different, but the process and methods of domain modeling and microservice development are similar. The core idea is to gradually break down the problem domain to reduce the complexity of understanding the business and implementing the system.

How to Understand Core Domain, Generic Domain, and Supporting Domain? #

In the process of continuous domain subdivision, domains can be further divided into different subdomains. Subdomains can be categorized into three types based on their importance and functional attributes. They are: core domain, generic domain, and supporting domain.

The core domain is the subdomain that determines the core competitiveness of a product and company. It is the main factor for business success and the core competitive advantage of the company. The generic domain is a functional subdomain that does not have many personalized demands and is used by multiple subdomains. The supporting domain is a functional subdomain that is necessary but does not include functions that determine the core competitiveness of a product or company, nor does it include generic functions.

Among these three types of subdomains, the core domain is the most important. We will provide a detailed introduction using the core domain as an example later. If we apply the concepts of generic domain and supporting domain to an enterprise system, for example, the generic domain would refer to the common systems needed, such as authentication and permissions. These applications are easily accessible and do not require much customization as they do not have specific enterprise characteristics. On the other hand, the supporting domain has enterprise-specific characteristics but lacks universality, examples of which include data code dictionaries and other similar systems.

So why do we divide the domains into core, generic, and supporting domains, and what is the main purpose?

Let’s continue with the example of a peach tree from the previous figure. We can divide the peach tree into six subdomains: root, stem, leaves, flowers, fruits, and seeds. But does the peach tree have a core domain? If so, which one is it?

Different people have different understandings of the peach tree. If this peach tree is growing in a park, the gardener may appreciate the “peach blossoms intermingling with human faces” in the bright spring of March, making the flowers the core domain of the peach tree. But if this peach tree is growing in an orchard, the fruit farmer will hope to harvest abundant peaches in the fruitful season, making the fruits the core domain of the peach tree.

In different scenarios, different people have different understandings of the core domain of the peach tree, and therefore, the way the peach tree is treated will also vary. The gardener focuses more on the nutrition during the flowering period, while the fruit farmer pays more attention to the nutrition during the fruiting period. Sometimes, in order to ensure the nutritional supply of the fruits, they may trim excessive stems and leaves (generic or supporting domain).

Similarly, in the process of IT system construction in a company, due to limited budget and resources, different subdomains should be given different levels of attention and resource allocation strategies. Remember, good steel should be used on the blade.

Many companies may have similar businesses on the surface, but their business models and strategic directions are significantly different. Therefore, the company’s focus will vary, and the results of dividing into core, generic, and supporting domains will also differ greatly.

For example, Taobao, Tmall, JD.com, and Suning are all e-commerce platforms, but each has a different business model. Taobao is a C2C website for individual sellers and buyers, while Tmall, JD.com, and Suning are B2C websites for company sellers and individual buyers. Even among B2C platforms like Suning and JD.com, their business models also differ. Suning is a typical traditional offline store transformed into an e-commerce platform, while JD.com is a combination of a direct-sales model and a platform.

The difference in business models leads to different results in the division of core, generic, and supporting domains. Some companies may have customer service as their core domain, while others may focus on product quality or logistics. When subdividing the domains, establishing domain models, and constructing systems in a company, it is important to consider the company’s strategic focus and business model in order to determine the core domain and focus on it.

If your company is interested in transitioning to a microservices architecture, I recommend that you and your technical team prioritize the development of the core domain. It is best to have absolute control and independent development capabilities for the core domain. If resources are limited, you can consider finding solutions for the supporting or generic domains, and outsourcing is also a viable option.

Summary #

The core idea of domain is to divide the problem domain into levels to reduce the complexity of business understanding and system implementation. By subdividing the domain, the problem domain that microservices need to solve can be gradually narrowed down, and appropriate domain models can be built, which are then mapped into the system as microservices.

The main goals of core domain, supportive domain, and generic domain are to differentiate the different subdomains in terms of their functional attributes and importance within the company. This allows the company to adopt different resource allocation and development strategies for different subdomains, with varying levels of attention.