11 DDD Practice - How to Reconstruct Middleware Business Models with DDD #
Hello, I am Ou Chuangxin.
After the year 2000, with the rapid development of Internet applications, many traditional enterprises began to go online and build their own Internet e-commerce platforms. Later, with the rise of mobile Internet applications such as WeChat and apps, a new wave of mobile applications emerged. Most of these mobile apps are aimed at individuals or third parties, and the market and demand change rapidly. In order to adapt to market changes at a faster pace, many times these mobile Internet applications are built independently of traditional core systems. However, both of them carry mostly homogeneous business, so it is easy to encounter problems of overlapping business capabilities.
Alibaba has driven the transformation of traditional enterprises to Internet e-commerce in the past. And now, in a new historical period, after Alibaba proposed its middle platform strategy, many enterprises have followed its footsteps, raised the middle platform banner high, and embarked on the road of digital transformation with great momentum.
So, when traditional enterprises undergo middle platform transformation, how should they construct a middle platform business model from complex business scenarios? Today, I will use a case of middle platform modeling in a traditional enterprise to show you how to construct a middle platform business model using the design thinking of Domain-Driven Design (DDD).
Analysis of Traditional Enterprise Applications #
Internet e-commerce platforms and traditional core applications target different channels and customers, but sell similar products. Their business models have both similarities and differences.
Now let’s compare and analyze the internet e-commerce and traditional core applications in the insurance industry. We can see from the following diagram that there are many similarities and differences in their business functions, which can be summarized in four aspects.
1. Repetitive construction of core capabilities. Due to the sale of homogeneous insurance products, similarities in core business processes and functions between the two are inevitable. Traditional core insurance applications have functions such as quoting, underwriting, policy checking, and policy issuing, which are also available in internet e-commerce platforms. This is the repetitive construction of core capabilities.
2. Repetitive construction of common capabilities. Traditional core applications usually have a large and comprehensive common platform, which tends to be heavy. Internet e-commerce platforms rely on these common capabilities, but in order to maintain agility, they generally build their own versions of common functions, such as user and customer management. This is the repetitive construction of common capabilities.
3. Separated construction of business functions. There is a class of business functions that are partially constructed in internet e-commerce platforms and traditional core applications. These functions do not overlap and complement each other. When combined, they form a complete business function. For example, the payment function. Internet e-commerce platforms mainly target individual customers and use payment methods such as Alipay and WeChat Pay. Traditional core applications mainly involve counter operations and still use mobile POS machines for payments. Both are payment functions. To ensure the completeness of the business model, when constructing a middleware business model, we can consider restructuring these two parts into one complete business model.
4. Independent construction of internet e-commerce platforms and traditional core functions. Traditional core applications primarily target counters and do not require online customer management, call center, order, and shopping cart functions provided by internet e-commerce platforms. Internet e-commerce platforms mainly target individual customers and do not require heavy back-end functions such as reinsurance, commission, and printing. When constructing a middleware business model, we should treat this situation differently by solidifying the applications that serve back-end business management into the background and building front-end capabilities as a general-purpose middleware for internet channels, such as order management.
How to Avoid Reinventing the Wheel? #
To avoid duplication of efforts, it is important to understand the concept and ideology of the middle platform. As mentioned earlier, the “middle platform is an enterprise-level capability reuse platform,” and “reuse” in simple words means using something repeatedly, which is exactly what we want to prevent when it comes to reinventing the wheel.
The design ideology of the middle platform is highly consistent with the principle of “high cohesion and low coupling”. High cohesion means gathering related business behaviors together and putting unrelated behaviors elsewhere. If you need to modify a certain business behavior, you only need to make changes in one place. Yes! This is exactly what the middle platform aims to do - achieving enterprise-level capability reuse based on the principle of “high cohesion and loose coupling”!
So, what should you do if your company is facing the situation of reinventing the wheel?
You need to think from an enterprise perspective and consolidate the repetitive, commonly shared capabilities and core capabilities into the middle platform. Rearrange the separated business capabilities into complete business modules, and build a reusable middle platform business model. Front-end personalized capabilities should be in the front-end, while back-end management capabilities should be in the back-end. Establish a clear boundary between the front-end, middle platform, and back-end, and create an enterprise-level collaborative and reusable business model.
How to Build a Middle Platform Business Model? #
We can use the DDD (Domain-Driven Design) modeling method to build a middle platform business model. You can choose between two modeling strategies: top-down and bottom-up. To determine which strategy to use, you need to analyze the specific situation of your company. Let me explain these two strategies.
1. Top-down strategy
The first strategy is top-down. With this strategy, you start with the top-level design and gradually decompose it into middle platforms, creating separate domain models based on business attributes, such as generic or core middle platforms. This domain modeling process is mainly based on the current business situation and does not consider the existing system. The top-down strategy is suitable for building new application systems or rebuilding old systems from scratch.
Since this strategy is not limited by existing systems, you can use the DDD domain decomposition method. The main steps include: 1) decomposing the domain into subdomains, which can be categorized as core, generic, or support domains; 2) modeling the subdomains, defining domain boundaries, and establishing domain models and bounded contexts; 3) designing microservices based on the bounded contexts.
2. Bottom-up strategy
The second strategy is bottom-up. With this strategy, you start by modeling the domains based on the current business and system situation. First, complete the domain modeling for each business domain the system is in. Then align the business domains and identify domain models that have similar or related business functionalities. Analyze the differences between the domain models and reorganize the domain objects to reconstruct the domain models. This process will consolidate common and reusable business capabilities, integrating scattered business models. The bottom-up strategy is suitable for the evolutionary reconfiguration of business models in legacy systems.
Now, let’s take a look at the following three steps to understand how to use the bottom-up strategy to build a middle platform business model, using the examples of internet e-commerce and traditional core applications with several typical business domains.
Step 1: Identify the system’s business domain and build domain models
Identify the business domain the system belongs to using event storming, and then find the domain objects, create aggregates, define bounded contexts, and build domain models. In the diagram below, we have selected five business domains: users, customers, traditional payments and receipts, underwriting, and internet e-commerce, as examples to complete the domain modeling.
From the diagram above, we can see that the traditional core application has built eight domain models. The user domain has two domain models: user authentication and permissions. The customer domain has two domain models: individual and group customers. The traditional payments and receipts domain has one domain model: POS card payments. The underwriting domain has three domain models: quoting, insurance, and policy management.
The internet e-commerce domain has six domain models: quoting, insurance, orders, customers, user authentication, and mobile payments.
In this list of domain models, you can see that there are many domain models with similar names. After thorough analysis, you will find that these similarly named domain models have duplicate business capabilities or dispersed business functions (such as mobile payments and traditional payments). When building a middle platform business model, you need to focus on these domain models, consolidate the duplicated business capabilities from different domain models into the middle platform business model, and integrate the dispersed domain models into a unified middle platform business model that provides shared services externally.
Step 2: Align business domains and build the middle platform business model
In the diagram below, you can see that there are clearly more traditional core domain models on the right side than internet e-commerce domain models on the left side. Based on this observation, we can draw a preliminary conclusion: the traditional core applications cater to most in-house applications, providing comprehensive domain models, while the internet e-commerce domain models are relatively focused on a single channel.
This conclusion suggests that we can use the domain models of traditional core applications as the main domain models and the internet e-commerce domain models as auxiliary models to build the middle platform business model. Then, the duplicated capabilities from the internet e-commerce domain models can be consolidated into the domain models of traditional core applications, while retaining their unique capabilities, such as orders. When building a middle platform business model, we need to focus both on the completeness of domain models and the agile response to market requirements in different channels.
With the above idea, we can start building the business model of the center platform.
We summarize and separate all the business subdomains that cover both the Internet e-commerce and traditional core domain models. Through analysis, we have identified five business domains that can be used as benchmark domains for domain model comparison analysis: users, customers, underwriting, payments, and orders.
Now I will take the customer as an example to explain the process of building the customer center platform business model.
The Internet e-commerce customer mainly targets individual customers. In addition to the personal customer information management function, it also has a customer loyalty points function for marketing purposes. Therefore, its domain model has two aggregates: personal and points.
The traditional core customer not only supports individual customers, but also includes group customers such as units and organizations. It has two domain models: personal and group. In addition to the personal customer information management function, the personal domain model also includes functions such as personal customer rating, merging of duplicate customers, and unified view of customers. Therefore, its domain model has four aggregates: personal, view, rating, and merge.
The process of building the business model of the center platform with multiple business domains is to find the domain models of all similar businesses within the same domain, compare and analyze the differences and commonalities between the domain models and aggregates within the domain, break the original models, and complete the process of reorganizing or merging the new business models of the center platform.
After decomposing the domain models of Internet e-commerce and traditional core, we found five aggregates related to individual customer domains, including: personal, points, rating, merge, and view. These five aggregates were originally dispersed in the domain models of Internet e-commerce and traditional core. We need to break the original domain models, conduct functional consolidation and aggregation, reidentify the bounded contexts of these aggregates, and reconstruct the domain models.
The final reconstruction of the domain model for individual customers is: The aggregates of personal, merge, and view are reconstructed into the personal domain model (customer information management), and the aggregates of rating and points are reconstructed into the rating and points domain model (targeting individual customers). With this, we have completed the construction of the domain model for individual customers.
Is there something missing? Oh, right, there is also the domain model for group customers! In fact, the group customer is quite simple. Since it only appears in the traditional core, we can directly use its domain model in the traditional core.
So far, we have completed the construction of the customer center platform business model, which includes the individual, group, and rating and points domain models.
Through the construction of the customer center platform business model, have you grasped the key points of building the business model of the center platform? In summary, it can be summed up as “domain modeling, finding benchmark domains, defining contexts, and aggregating and reclassifying”.
The same process applies to other business domains. I won’t go into detail here, but you can practice it yourself as homework. After completing it, you can compare it with the following diagram, which shows the reconstructed business models of other business domains.
Step 3: Classify the center platform and design microservices based on the domain model.
After completing the business modeling of the center platform, we have the following diagram. From this diagram, we can see how many center platforms have been built, which domain models are included under each center platform, which center platforms are general-purpose, which are core, and other basic information about the center platforms. With the domain models under the center platforms, you can design microservices.
Domain Objects in the Refactoring Process #
The above mainly describes the reorganization of the business model of the central platform from the perspective of aggregations, which is a relatively high-level refactoring of business modules. Business model refactoring and aggregation restructuring often lead to changes in domain objects and business behaviors. Now let me introduce to you the activities of the domain objects that occur at a lower level during the domain model refactoring process.
Let’s continue using the example of customers to illustrate. Due to the large number of objects, I have only selected some domain objects and business behaviors.
Before the traditional core customer domain model refactoring, it included three aggregations: individual, group, and rating. Each aggregation has its own aggregate root, entities, methods, domain services, etc.
Before the refactoring of the Internet e-commerce customer domain model, it included two aggregations: individual and points. Each aggregation included its own domain objects, methods, domain services, etc.
After the refactoring of the traditional core and internet e-commerce customer domain models into the customer middleware, three domain models were established: individual, group, and rating points. The individual domain model has the individual aggregation, the group domain model has the group aggregation, and the rating points domain model has the rating and points aggregations. The domain objects of these domain models come from the original domain models, but the rating points are new domain models formed by the restructuring, and their original aggregations are added to the new domain models.
It is worth noting here that some domain objects may be separated from their original aggregations and restructured into other aggregations based on new business requirements. The domain objects of the new domain models, such as entities and domain services, may also undergo code refactoring based on new business scenarios and requirements.
Summary #
Today we discussed the digital transformation of traditional enterprise middleware. When faced with repeated construction of multiple different channel applications, we discussed how to use the DDD (Domain-Driven Design) mindset to build a middle platform business model. There are two strategies for modeling middle platform businesses: top-down and bottom-up. Each strategy has its own suitable scenarios, so you need to choose the appropriate strategy based on your company’s situation.
In fact, the process of refactoring the middle platform business model is also the evolution process of microservice architecture. When the business boundaries are well defined, the boundaries of microservices will naturally be well defined.