10 DDD Middleware and Microservices - How They Collaborate #

Hello, I am Ou Chuangxin. Today, let’s talk about the relationship between DDD, Center of Excellence, and Microservices.

DDD and Microservices originated from the West, while the concept of Center of Excellence was born in Alibaba in China. DDD has been quietly advancing since it was proposed over twenty years ago, while the ideas of Center of Excellence and Microservices have gained popularity in recent years. These three may seem unrelated, but they are closely connected. The Center of Excellence is an abstracted business model, Microservices is the system implementation of the business model, and DDD, as a methodology, can guide both the modeling of the Center of Excellence and the construction of Microservices. They complement each other and work together seamlessly.

You may ask: why can DDD guide the construction of the Center of Excellence and Microservices, and what role does it play exactly?

DDD has two powerful tools, namely its strategic design and tactical design methods.

The Center of Excellence focuses more on the business model in enterprise architecture, and the process of establishing the Center of Excellence is actually a continuous subdivision of the business domain. In this process, we aggregate and reconstruct similar and generic business capabilities, and then establish domain models based on the principles of bounded contexts and business cohesion. The strategic design of DDD excels at domain modeling.

After completing the domain modeling in the Center of Excellence, we need to implement the system using Microservices. At this point, the tactical design of DDD can be perfectly combined with the design of Microservices. It can be said that the Center of Excellence and Microservices are the best scenarios for implementing DDD in practice.

The Essence of DDD #

Let’s start by briefly reviewing the concepts of domain, subdomain, core domain, generic domain, and supporting domain in DDD, which we will use later.

When researching and solving business problems, DDD subdivides the business domain according to certain rules. After the domain is subdivided to a certain extent, DDD will limit the scope of the problem within a specific boundary and establish a domain model within this boundary. The domain model is then implemented with code to solve the corresponding business problems. A domain can be decomposed into subdomains, and subdomains can be further divided into sub-subdomains until you think it is appropriate to establish a domain model.

Subdomains are also divided into three categories based on their importance and functional attributes. They are core domains, supporting domains, and generic domains. For a more detailed explanation of these three types of subdomains, you can refer to [Lesson 02].

Next, let’s take a look at the diagram above. I have selected several important domains in the insurance industry and performed a high-level domain division. Of course, the domain positioning and responsibilities may vary for each company, so there will definitely be some differences in the division of core domains. Therefore, when you do domain division, please make sure to consider the company’s strategy, which also reflects the importance of DDD domain modeling.

Through domain division and further subdomain division, we can distinguish the functional attributes and importance of different subdomains within the company. In turn, this allows us to adopt different resource investment and construction strategies, which is crucial in the process of developing enterprise IT systems. Moreover, such division can also assist companies in designing their middle platforms.

The Essence of the Platform #

The concept of the platform originates from Alibaba’s platform strategy (see “The Art of Enterprise IT Architecture Transformation: Alibaba’s Platform Strategy and Architectural Practices” by Hua Zhong). In late 2015, Alibaba Group announced the comprehensive launch of the platform strategy, aiming to establish a more innovative and flexible “large-scale platform with a small-scale front-end” organizational and operational mechanism that is suitable for the digital era. This means that front-line businesses, as the front-end, can adapt to the rapidly changing market more agilely and quickly, while the platform will consolidate the operational data capabilities and product technological capabilities of the entire group, providing strong support to various front-line businesses.

The essence of the platform is essentially to extract common requirements from various business sectors, perform business and system abstractions, create reusable and universal business models, and develop modularized products for use by front-end departments. Front-end departments can directly approach the platform for any business needs or resources, without needing to make changes to their own underlying systems every time.

Collaboration Model of DDD, Platform Domain, and Microservices #

In [Lesson 09], we have discussed the differences between traditional enterprises and Alibaba’s platform domain strategy. However, many enterprises still focus on the construction of the traditional enterprise platform, which means centralizing common capabilities and core capabilities into a platform to enable the reuse of core business capabilities across different channels. So, let’s continue to focus on traditional enterprises.

Traditional enterprises can model the shared common capabilities as a domain and build a General Platform that can be shared across different domains. In addition to this, traditional enterprises will also model the core capabilities into domains and build a reusable Core Platform for different channels.

Both the General Platform and Core Platform mentioned here belong to the category of Business Platforms discussed in the previous lesson.

DDD subdomains can be divided into Core, Generic, and Support Domains. The main purpose of dividing these subdomains is to determine strategic resource allocation. Generally, the strategic investment focus is on the Core Domain, so we can temporarily not strictly distinguish between Support and Generic Domains.

Although Domain, Platform Domain, and Microservices belong to different levels, we can still compare and summarize their relationships. Take a look at the following diagram, where I analyze the business architecture of an enterprise from the perspectives of DDD Domain Modeling and Platform Construction.

If we consider the entire business domain within an enterprise as a problem domain, then all the business activities within the enterprise form a domain. When dividing the domain, from the perspective of DDD, it can be divided into Core Domain, Generic Domain, and Support Domain. From the perspective of platform construction, the business domain subdivided into business platforms can be divided into Core Platform and General Platform.

From the comparison of domain function attributes and importance, the General Platform corresponds to DDD’s Generic Domain and Support Domain, while the Core Platform corresponds to DDD’s Core Domain. In terms of the functional scope of the domain, the subdomains are consistent with the platforms. The bounded context in which the domain model exists corresponds to microservices. Establishing this mapping relationship allows us to use DDD for platform business modeling.

Let’s take the insurance domain as an example. The business platform in the insurance domain can be divided into two categories: the first category is the Core Platform that provides core insurance business capabilities (such as marketing, underwriting, and claims); the second category is the General Platform that supports the completion of the entire insurance process (such as orders, payments, customers, and users).

Here, I want to remind you that according to the principles of DDD, we should establish a common language first. When introducing DDD methods into platform design, we need to establish a common language between the platform and DDD. The subdomains are consistent with the platforms, so we can unify the subdomains as platforms.

The platform can be further divided through event storming, ultimately completing the business domain modeling. Depending on the different functionalities of the platform’s business domains, the number and size of bounded contexts will vary, and the domain models will also be different.

Once the business modeling is completed, we can use DDD tactical design to design domain objects such as aggregates, entities, domain events, domain services, and application services, and then use a layered architecture model to design microservices.

The above is the collaboration model of DDD, Platform Domain, and Microservices in the application process.

How to model a middle platform? #

After understanding the collaboration mode of the three entities, let’s continue discussing how to model a middle platform.

The process of abstracting middle platform business is the process of business modeling, corresponding to the strategic design of DDD (Domain Driven Design). The process of abstracting systems is the process of developing microservices, corresponding to the tactical design of DDD. Now let’s discuss the process of middle platform business modeling, combining with the domain modeling method of DDD.

Step 1: Divide the business domain into multiple middle platforms based on business processes (usually suitable for core domains) or functional attributes/collections (usually suitable for generic or support domains), and then classify them into core middle platforms or generic middle platforms based on functional attributes or importance. When designing core middle platforms, core competitiveness should be considered, and when designing generic middle platforms, sharing and reuse capabilities should be considered at an enterprise level.

Step 2: Choose a middle platform, complete the event storming based on use cases, business scenarios, or user journeys, and identify entities, aggregates, and bounded contexts. Conduct domain decomposition and establish domain models in sequence.

Because different middle platforms have independent modeling, certain domain objects or functions may appear repeatedly in other domain models, or domain objects or functions that should belong to the same aggregate may be dispersed among other middle platforms. This may lead to incomplete domain models or lack of business cohesion. But don’t worry about it at this stage. In this step, we only need to preliminarily determine the main domain model. In the next step, we will refine and reorganize these domain objects.

Step 3: Based on the main domain model, scan other middle platform domain models to check and determine whether there are duplicate domain objects or functions that need to be reorganized. Refine and reconstruct the main domain model to complete the final domain model design.

Step 4: Repeat the third step with other main domain models until all main domain models are compared and reorganized.

Step 5: Design microservices based on the domain model and complete the implementation of the system.

Combining the above diagram, you can roughly understand the process of middle platform design in DDD. DDD’s strategic design includes the first to fourth steps mentioned above, mainly: decomposing the business domain into middle platforms, classifying the middle platforms, completing domain modeling, and establishing the middle platform business model. DDD’s tactical design is the fifth step, mapping the domain model to microservices, and completing the construction of the middle platform.

Using the insurance domain as an example, after completing the domain modeling, we can fill in the data. Here, I selected three middle platforms in the generic domain: user, customer, and order, as examples. The customer middle platform has two domain models: customer information and customer view model. The user middle platform has three domain models: user management, login authentication, and authorization model. The order middle platform has the order model.

This is the complete process of middle platform modeling. However, behind the apparent simplicity, various problems may arise when dealing with complex business scenarios, otherwise there would not be so many difficulties in applying it. If you encounter any problems during implementation according to the above process, feel free to discuss with me in the comments section.

Summary #

Today we mainly discussed some ideas about the construction of a central platform in traditional enterprises, and clarified the relationship between DDD, central platforms, and microservices. The strategic design of DDD can be used for business modeling in central platforms, and the tactical design can guide the design of microservices in central platforms. We believe that the perfect combination of DDD and central platforms can greatly enhance the construction of your central platform!

Furthermore, this lecture is just the beginning. In the next lecture, I will provide a detailed explanation of the design process for a central platform in a traditional core business, using a case study.