In this article, let's talk about the relationship between DDD, middle platform and microservices.
DDD and microservices originated from the West, while Zhongtai was born in Alibaba in China. DDD has been moving forward silently since it was proposed more than 20 years ago. The concept of middle platform and microservices has only appeared in recent years, and it has become very popular since it was proposed. These three seem to be irrelevant, but in fact they are closely related. The middle platform is an abstracted business model, and the microservice is the system realization of the business model. As a methodology, DDD can guide the business modeling and microservice construction of the middle platform at the same time. The three complement each other and are perfectly combined.
Some people may ask: Why can DDD guide the construction of middle-end and micro-services, and what role does it play?
DDD has two sharp weapons, that is, its strategic design and tactical design methods.
The middle office is more biased towards the business model in terms of enterprise architecture, and the process of forming the middle office is actually a process of continuous subdivision of the business field. In this process, we will aggregate and restructure common business capabilities of the same kind, and then build a domain model based on the principles of bounded context and business cohesion. And what DDD's strategic design is best at is domain modeling.
After completing the domain modeling in the middle platform, we need to complete the system construction through microservices. At this time, the tactical design of DDD can be perfectly combined with the design of microservices. It can be said that the middle platform and microservices are the best scenarios for DDD actual combat.
The essence of DDD
Let's briefly review the concepts of DDD domains, subdomains, core domains, general domains, and support domains, which will be used later.
When researching and solving business problems, DDD will subdivide the business domain according to certain rules. After the domain is subdivided to a certain extent, DDD will limit the scope of the problem to a specific boundary, and establish a domain model within this boundary , and then implement the domain model with code to solve the corresponding business problems.
Domains can be broken down into subdomains, and subdomains can be further subdivided into subsubdomains, until you see fit to model the domain. Subdomains are also divided into three types of subdomains according to their own importance and functional attributes, which are core domains, supporting domains and general domains. For a more detailed explanation of these three types of subdomains, you can refer back to [Domain, Subdomain, Core Domain, General Domain, and Support Domain: Stupidly confused] .
Next, let's take a look at the above picture together. I selected several important areas of insurance and carried out high-level domain division. Of course, the field positioning and responsibilities of each enterprise will be somewhat different, so there will definitely be some differences in the division of core domains. Therefore, when you do domain division, please be sure to combine it with corporate strategy, which just reflects the importance of DDD domain modeling.
Through domain division and further sub-domain division, we can distinguish the functional attributes and importance of different sub-domains in the enterprise, and then adopt different resource investment and construction strategies, which are very important in the construction process of enterprise IT systems, and Such a division can also help companies design mid-stage.
The essence of Zhongtai
Zhongtai comes from Ali's Zhongtai strategy (see "Enterprise IT Architecture Transformation: Alibaba's Zhongtai Strategic Thought and Architecture Actual Combat" edited by Zhong Hua). At the end of 2015, Alibaba Group announced the comprehensive launch of the China-Taiwan strategy to build a more innovative and flexible organizational mechanism and business mechanism of "large, medium-sized and small front desks" in line with the digital age. Agile and faster to adapt to the ever-changing market, and the middle office will integrate the operational data capabilities and product technology capabilities of the entire group to form a strong support for each front-end business.
The essence of Zhongtai is actually to refine the common needs of various business sectors, abstract business and systems, form a common and reusable business model, and create componentized products for the front-end department to use. What kind of business does the front desk want and what resources do they need? You can go to the middle desk directly, and you don’t need to change your bottom layer every time.
The collaboration model of DDD, middle platform and microservice
We are in [Zhongtai: What should we share after digital transformation? 】 I have already mentioned the differences between traditional enterprises and Ali’s China-Taiwan strategy. In fact, more companies will still focus on the traditional enterprise’s China-Taiwan construction model, that is, to centralize all general and core capabilities to meet different needs. The reuse of channel core business capabilities, then we will still focus on traditional enterprises.
Traditional enterprises can model the public capabilities that need to be shared , and build a common platform that can be shared. In addition, traditional enterprises will also conduct domain modeling of core capabilities and build a reusable core middle platform for different channels.
Both the general middle platform and the core middle platform here belong to the category of the business middle platform mentioned in our previous article.
The subdomains of DDD are divided into core domain, general domain and support domain. The main purpose of dividing these sub-domains is to determine the investment of strategic resources. Generally speaking, the focus of strategic investment is the core domain, so we can temporarily not strictly distinguish between the support domain and the general domain.
Although the domain, middle platform, and microservices belong to different levels, we can still decompose and compare them to sort out the relationship between them. Look at the picture below. I am analyzing the business architecture of the same enterprise from two different perspectives: DDD domain modeling and middle platform construction.
If the entire business domain within an enterprise is regarded as a problem domain, all businesses within an enterprise are a domain. When subdividing domains, from a DDD perspective, subdomains can be divided into core domains, general domains, and support domains. From the perspective of middle platform construction, the business middle platform after business domain segmentation can be divided into core middle platform and general middle platform.
From the comparison of domain function attributes and importance, the general middle platform corresponds to the general domain and support domain of DDD, and the core middle platform corresponds to the core domain of DDD. From the functional scope of the domain, the sub-domain is consistent with the middle office. The bounded context where the domain model resides corresponds to the microservice. After establishing this mapping relationship, we can use DDD to model middle-end business.
Here we still take the insurance field as an example. The business center of the insurance domain is divided into two categories:
- The first category is the core middle office that provides insurance core business capabilities (such as marketing, underwriting and claims);
- The second category is the general middle platform that supports the core business process to complete the entire insurance process (such as orders, payments, customers and users, etc.).
Here I would like to remind you: According to the principle that DDD must first establish a common language, when introducing the DDD method into the middle platform design, we must first establish a common language between the middle platform and DDD. The subdomain here is consistent with the middle platform, so we can unify the subdomain as the middle platform.
The middle office can be further subdivided through event storms, and finally complete the business domain modeling. The functions of the middle-end business domain are different, the number and size of bounded contexts will be different, and the domain model will also be different.
After completing business modeling, we can use DDD tactical design to design domain objects such as aggregation, entities, domain events, domain services, and application services, and then use the layered architecture model to complete the design of microservices.
The above is the collaboration mode of DDD, middle platform and microservices in the application process.
How to model the middle platform?
After reading the cooperation mode of the three, let's follow the above topic, and then talk about how the middle platform models.
The process of business abstraction in the middle office is the process of business modeling, which corresponds to the strategic design of DDD. The process of system abstraction is the construction process of microservices, which corresponds to the tactical design of DDD.
Next, we will combine the DDD domain modeling method to talk about the process of middle-end business modeling.
- Step 1: Subdivide the business domain into multiple middle stations according to the business process (usually applicable to the core domain) or functional attributes and collections (usually applicable to the general domain or support domain), and then classify according to the functional attributes or importance Go to the core middle platform or the general middle platform. Core competitiveness should be considered in the design of the core middle platform, and sharing and reuse capabilities should be considered from the perspective of the enterprise in the general middle platform.
- Step 2: Select the middle platform, complete the event storm according to the use case, business scenario or user journey, and find out the entity, aggregation and bounded context. Decompose the domain sequentially and establish the domain model. Due to the independent modeling of different middle platforms, some domain objects or functions may appear repeatedly in other domain models, or the same aggregated domain objects or functions may be scattered in other middle platforms, which will lead to The domain model is incomplete or the business is not cohesive. Don't worry here. In this step, we only need to initially determine the main domain model. In the third step, we will refine and reorganize these domain objects.
- Step 3: Based on the main domain model, scan other mid-stage domain models, check and determine whether there are duplicate or restructured domain objects and functions, refine and reconstruct the main domain model, and complete the final domain model design.
- Step 4: Select other main domain models and repeat step 3 until all main domain models are compared and reconstructed.
- Step 5: Complete the microservice design based on the domain model and complete the system implementation.
Combined with the above picture, you can roughly understand the process of DDD middle station design. The DDD strategic design includes the above-mentioned first step to the fourth step, mainly: the business domain is decomposed into the middle office, the middle office is classified, the domain modeling is completed, and the middle office business model is established. DDD tactical design is the fifth step. The domain model is mapped to microservices to complete the construction of the middle platform.
So if we still take the insurance field as an example, after completing the domain modeling, we can fill in the data in it. Here I choose the three middle platforms of users, customers and orders in the general middle platform as examples. Two domain models are extracted in the customer center: customer information and customer view model. Three domain models are extracted in the user center: user management, login authentication and permission model. The order model is extracted in the order center.
This is the whole process of mid-stage modeling. Of course, behind the seemingly simple, if you encounter complex business, there will always be various problems, otherwise it will not be so difficult to apply.
Summarize
Today we mainly discussed some ideas for the construction of traditional enterprises' middle platform, and sorted out the relationship between DDD, middle platform and microservices. The strategic design of DDD can be used for business modeling in the middle office, and the tactical design can guide the design of microservices in the middle office. I believe that the perfect combination of DDD and China-Taiwan can make your China-Taiwan construction even more powerful!