A microservice splitting method based on a demand model

Abstract

A microservice splitting method based on a demand model is provided, which takes the demand model as the input of the microservice decomposition method, and generates a group of microservice boundaries as the output after four steps of use case model splitting, mapping of the use case model splitting result to the domain model, division result checking and refinement, and microservice extraction. The microservice is divided based on the process and data, and the final microservice architecture is obtained by comprehensive consideration.

Description

Technical Field

[0001] This invention relates to the field of microservice architecture, and more specifically to a microservice decomposition method based on a requirement model. Background Technology

[0002] Microservice architecture is an architectural concept that aims to decouple solutions by breaking down functionality into discrete services. Compared to traditional architectures, it offers advantages such as high scalability, high reliability, and cross-language compatibility. A poorly designed microservice system is more difficult to maintain than a large monolithic system. Therefore, finding a way to ensure the quality of microservice architecture by adhering to principles such as single responsibility, high cohesion and low coupling, and appropriate service granularity has become a major challenge for the industry.

[0003] The existing approach to microservice decomposition primarily uses Domain-Driven Design (DDD): DDD is a business-level partitioning method that mainly consists of two phases: domain model design and domain model-driven software design. A domain model encompasses both entity and process concepts, as well as attributes and methods; it is a collection of abstract concepts. Since the domain model is a design model, the transformation from a requirements model to a domain model requires the involvement of domain experts. Its design steps include preliminary scenario analysis, domain modeling, and microservice design and decomposition.

[0004] Although Domain-Driven Design (DDD) is widely accepted in the industry, this microservice decomposition method still has the following problems: 1) DDD first requires professional domain partitioning, a process that requires the participation of domain experts to define entities, aggregates, and the domain model. However, in reality, this step is difficult to implement in many microservice architecture scenarios. 2) DDD is highly theoretical. Because it is impossible to simultaneously satisfy all the conditions in the theory, it is very difficult to build a complete and self-contained domain model, which results in very few projects being able to perfectly implement DDD. 3) The domain model usually omits the information necessary to infer microservices. In addition, it lacks basic structural components, so DDD requires designers to invest a lot of effort.

[0005] This patent proposes a microservice decomposition method based on a requirement model. This method can automatically, quickly, and directly generate microservice architectures, thus overcoming the shortcomings of the DDD method, such as complexity and strong conceptualization. The requirement model used in the requirement model-based microservice decomposition method consists of use case diagrams, system sequence diagrams, conceptual class diagrams, and system operation contracts. The conceptual class diagram is similar to a domain model, but it only contains attributes. Decomposing microservices directly from requirements eliminates the step of building a domain model, enabling the automatic generation of microservice architectures without the need for domain experts, saving costs and improving the efficiency of building microservice architectures. Summary of the Invention

[0006] The invention provides a microservice decomposition method based on a requirement model, aiming to achieve automatic generation of microservice architecture from the requirement model, while solving problems such as large workload and complex domain model building in traditional methods.

[0007] To achieve the above-mentioned objectives, the present invention provides the following technical solution:

[0008] A microservice decomposition method based on a requirement model is proposed. The method takes the requirement model as the input of the microservice decomposition method and goes through four steps: use case model decomposition, mapping the use case model decomposition results to the domain model, checking and refining the decomposition results, and extracting microservices, and finally generating a microservice architecture.

[0009] The UML requirement model is used as the input for the microservice decomposition method. The UML requirement model consists of use case diagrams, system sequence diagrams, conceptual class diagrams, and system operation contracts.

[0010] The specific algorithm for splitting the use case model is as follows: First, the list of use case objects is used as input parameters. Each use case object has a tag field, which indicates whether the use case object is a basic use case, an included use case, or an extended use case. The algorithm checks the tag field to determine the object type and calls the corresponding method. When the algorithm determines that the use case is a basic use case, it creates a microservice object for that basic use case. Conversely, when the use case object is an included use case or an extended use case, the algorithm adds the use case object to its parent use case microservice object. The parent use case of an included use case or an extended use case is the use case at the other end of its corresponding relationship.

[0011] The specific method for mapping the use case decomposition results to the domain model is as follows: For each microservice object obtained from the use case model decomposition model, each use case contained in the microservice object is accessed sequentially. Each use case corresponds to a system sequence diagram to represent its system function. The system sequence diagram contains multiple system operations. The object referenced by the system operation can be determined through the system operation contract corresponding to the system operation. This continuous calling process is defined as a call chain. A microservice is mapped to a set of objects through the call chain. This set of objects is then mapped to the domain model. Objects in the same set are divided into a boundary context as a data set of a microservice. After dividing the boundary context, a user interface is added to each microservice. The methods defined in the interface contain all the system operations possessed by the use case set. In addition, a system interface for interaction between microservices needs to be defined. The system interface is used to represent the interaction relationship between objects in different boundary contexts in the domain model. Bidirectional relationships establish bidirectional interfaces, and unidirectional relationships establish unidirectional interfaces.

[0012] The specific method for checking and refining the splitting results is as follows: The domain model models the relationships between system objects, and uses a list of keywords describing cohesion to identify which objects need to be packaged together; for an object, if a certain association name of the object is found in the keyword list, it is necessary to examine the position of the object at the other end of the relationship. The following situations may occur: 1. The objects at both ends of the keyword are in the same boundary context; 2. The two are not in the same boundary context; Situation 1 is a verification of the previous splitting results, indicating that the splitting is correct and reasonable, while situation 2 indicates that there is an uncertain state in the microservice splitting.

[0013] The specific method for determining the uncertain state of the microservice partitioning is as follows: For each object, if there is a relationship represented by a certain keyword, then define that the object is used once by the microservice object where the other end of the relationship is located, and finally place the object in the microservice object that has been used the most. If the number of uses is the same, then place it in the original microservice object first.

[0014] The beneficial effects achieved by this invention are as follows: This invention independently divides microservices from data and processes, and finally summarizes the two division results to obtain the final microservice architecture. This invention can quickly and efficiently generate high-quality microservice frameworks, allowing developers to focus their main efforts on requirement model generation, thereby improving the efficiency of building microservice architectures. Attached Figure Description

[0015] Figure 1 This is the microservice decomposition process of the present invention.

[0016] Figure 2 This is a schematic diagram of the splitting algorithm 1.

[0017] Figure 3 This is a mapping relationship between the use cases and objects of this invention.

[0018] Figure 4 This describes the implementation process of the boundary context interface.

[0019] Figure 5 The microservice architecture obtained by Algorithm 2.

[0020] Figure 6 This serves as an example for the validation and refinement of a microservice architecture.

[0021] Figure 7 This is the final microservice architecture represented by a component diagram. Detailed Implementation

[0022] To enable a clear understanding of the objectives and advantages of this invention, the following detailed description of the invention is provided in conjunction with the accompanying drawings and specific embodiments.

[0023] I. Methods and Steps

[0024] The steps of microservice decomposition based on a demand model are as follows: Figure 1 As shown, the UML requirement model serves as the input to the microservice decomposition method. After four steps—use case model splitting, mapping the use case model splitting results to the domain model, dividing the bounded context, and extracting microservices—a microservice architecture is generated.

[0025] II. Input Requirements Model

[0026] This method requires a requirements model as input. A UML requirements model consists of use case diagrams, system sequence diagrams, conceptual class diagrams, and system operation contracts. For existing systems, this means finding and reusing requirements documents. If an updated requirements model document is unavailable, it is recommended to develop a requirements model that matches the current system so that the generated microservices are consistent with the business functionality of the current system.

[0027] III. Use Case Model Decomposition

[0028] Use case diagrams are used to model system functional requirements, providing sufficient system information to decompose the overall system into microservices. First, the list of use case objects in the use case diagram is taken as input. Each use case object has a label field indicating whether it is a base use case, an included use case, or an extended use case. The algorithm checks this label field to determine the object type and calls the corresponding method. When the algorithm determines that the use case is a base use case, it creates a microservice object for that base use case. Conversely, if the use case object is an included or extended use case, the algorithm adds the use case object to its parent use case microservice object. The parent use case of an included or extended use case is the use case at the other end of its relationship. This decomposition algorithm splits the set of use cases into multiple smaller sets, each corresponding to a microservice object.

[0029] Algorithm 1 introduces the algorithm for decomposing the use case model. This algorithm takes a list of use case objects as input. Each use case object has a flag field indicating whether it is a base use case, an extended use case, or a included use case. The algorithm checks this flag field, and after determining the object's type, it calls the corresponding method for the use case object. When the algorithm determines that a use case is a base use case, it calls the `createMicroserviceObject()` method with the use case object as input to create a microservice object.

[0030] Conversely, if it is not a base use case (i.e., an included or extended use case), the algorithm executes the addToParentMSObject() method to add the use case object to the parent use case microservice object. Thus, the included or extended use case becomes part of the base use case's microservice object.

[0031]

[0032] Algorithm 1 implements the decomposition of use cases into microservices, which is the first and initial iteration of decomposing the overall system. The decomposition process of Algorithm 1 is as follows: Figure 2 As shown.

[0033] IV. Mapping Use Case Decomposition Results to the Domain Model

[0034] After obtaining the microservice objects, they need to be mapped onto the domain model (conceptual class diagram).

[0035] For each microservice derived from the use case model decomposition, each use case contained within the microservice is accessed sequentially. Each use case corresponds to a system sequence diagram representing its system function. A system sequence diagram consists of a set of system operations. Each system operation corresponds to a system operation contract; therefore, the object operated by the corresponding system operation can be found based on the system operation contract. The mapping relationship between use cases and objects is as follows: Figure 3 As shown, this continuous call relationship is called a "call chain". Through the above steps, a microservice can be mapped to a collection of objects, which is a dataset of microservice objects. In the domain model, all objects in a collection are grouped into a microservice boundary, thus achieving the division of the microservice boundary.

[0036] After defining the boundary context, a user interface needs to be added to each microservice. The name of the user interface is defined as the name of the parent use case in each use case set, and the methods defined in the user interface include all system operations possessed by the use case set (such as...). Figure 4 (As shown). In addition, system interfaces for interaction between microservices need to be defined. System interfaces are used to represent the interaction relationships between objects in different boundary contexts in the domain model. Bidirectional relationships establish bidirectional interfaces, and unidirectional relationships establish unidirectional interfaces. The "call chain" mapping and user interface generation process can be represented by Algorithm 2.

[0037] After the partitioning process using Algorithm 1 and the mapping process using Algorithm 2, a preliminary microservice framework has been obtained, such as... Figure 5 As shown above, the steps are a process-based microservice decomposition method, which also needs to be supplemented by a data-based decomposition method.

[0038]

[0039]

[0040] V. Inspection and Refinement of Splitting Results

[0041] The domain model is validated and refined from the perspective of business objects. The domain model models the relationships between system objects, using a list of keywords describing cohesion to identify which objects need to be packaged together. Keywords describing connecting objects are determined by domain experts based on business functions, and the keyword list includes verbs such as has, hold, owns, and contains. Relationships described by cohesion keywords indicate a high degree of association between objects, making it necessary to group them into the same microservice. For an object, if a relationship name is found in the keyword list, the position of the object at the other end of the relationship needs to be examined. The following situations may occur: 1. The objects at both ends of the keyword are within the same boundary context. 2. They are not within the same boundary context (e.g., ...). Figure 6 (See the LineItem shown). The occurrence of scenario 1 validates the previous microservice partitioning result, indicating that the previous partitioning was reasonable. Scenario 2 indicates that the microservice partitioning has an uncertain state. The handling of uncertain microservice states is as follows: For each object, if a relationship exists represented by a certain keyword, then define that object to be used once by the microservice object containing the object at the other end of the relationship, such as... Figure 6 The LineItem object in the microservice is used twice by the placeOrder microservice and once by the manageCart microservice. Ultimately, the object is placed in the microservice object with the highest usage count; if the number of uses is the same, it is placed in the original microservice object first. Figure 6 The LineItem object in the `placeOrder` microservice is used most frequently, so no adjustments are needed. This step performs a check and refinement of the original splitting results from a data perspective.

[0042] The above process is summarized by Algorithm 3. The input is the domain model (DM) with boundary context obtained by Algorithm 2 and the keyword list. Each object is traversed, and it is added to the microservice object that uses the object most frequently. Through fine-tuning the microservice boundary context, a refined microservice architecture is finally obtained.

[0043]

[0044]

[0045] VI. Extracting Microservices

[0046] Each boundary context defines a single microservice, and each microservice defines the user interface and the system interface for interacting with other microservices. This generates the final microservice architecture, which is represented by a component diagram, such as... Figure 7 As shown.

Claims

1. A method for microservice splitting based on a demand model, characterized in that: Adopting the demand model as the input of the micro-service decomposition method, after four steps of use case model splitting, mapping the splitting result of the use case model to the domain model, checking and refining the splitting result, and extracting micro-services, the micro-service architecture is finally generated, adopting the UML demand model as the input of the micro-service decomposition method, the UML demand model is composed of a use case diagram, a system sequence diagram, a concept class diagram and a system operation contract, wherein, The specific algorithm of the use case model splitting is as follows: firstly, taking the use case object list as the input parameter, each use case object has a mark field, which indicates that the use case object is one of a basic use case, a contained use case and an extended use case; the algorithm checks the mark field to determine the object type to call the corresponding type method, when the algorithm determines that the use case is a basic use case, a micro-service object is created for the basic use case, otherwise, the use case object is added to the parent use case micro-service object, and the parent use case of the contained use case or the extended use case is the use case at the other end of the corresponding relationship; The specific method of mapping the use case splitting result to the domain model is as follows: for each micro-service object obtained by the use case model splitting model, firstly, each use case contained in the micro-service object is accessed in turn, each use case corresponds to a system sequence diagram to represent its system function, the system sequence diagram contains multiple system operations, and the object referenced by the system operation can be determined through the system operation contract corresponding to the system operation, and the continuous calling process is defined as a calling chain; an object set is mapped to a micro-service through the calling chain, and the object set corresponds to the domain model, the objects in the same set are divided into a bounded context as a data set of a micro-service, after the bounded context is divided, a user interface is added to each micro-service, and the methods defined in the interface contain all system operations of the use case set; in addition, a system interface for interaction between micro-services needs to be defined, the system interface is used to represent the interaction relationship between objects in different bounded contexts in the domain model, a bidirectional relationship establishes a bidirectional interface, and a unidirectional relationship establishes a unidirectional interface; The specific method of checking and refining the splitting result is as follows: the domain model models the relationship between system objects, and uses a keyword list describing the cohesion relationship to identify which objects need to be packaged together; for an object, if it is found that the name of a certain association relationship of the object exists in the keyword list, the position of the object at the other end of the relationship needs to be investigated, and the following cases can occur: case 1: the objects at both ends of the keyword are in the same bounded context, case 2: the two are not in the same bounded context, if case 1 occurs, it is a verification of the previous division result, indicating that the division is correct and reasonable, and if case 2 occurs, it indicates that the micro-service division is in an uncertain state.

2. The microservice splitting method of claim 1, wherein The specific method for determining the uncertain state of the micro-service division is as follows: For each object, if there is a relationship represented by a certain keyword, then define the object is used by the micro-service object on the other end of the relationship once, and finally put the object in the micro-service object that is used the most, if the number of uses is the same, then prefer to put in the original micro-service object.

Images