A method for constructing domain model process

Abstract

The present application discloses a method for constructing a domain model process, which belongs to the field of domain-driven design, PaaS platform, and business middle platform technology. Specifically, it is a method for constructing a domain model process, including product vision analysis, business process diagram, business key node analysis, business rule analysis, instruction parameter analysis, extraction of domain objects, determination of aggregate roots, optimization of aggregate roots, component views, reverse reasoning, data model design, developer coding and development design process scoring, and unified language. On the basis of a unified product vision, business personnel, developers, architects, product personnel, and testers can all use the business knowledge of each role to build a domain model diagram that everyone can understand. This methodology allows each role in the software life cycle to form a high degree of ideological unity based on the domain model diagram as a reference and the scoring criteria as an inspection tool, thereby achieving a high degree of unity from business needs, product design, code development, and test cases.

Description

Technical Field

[0001] This application relates to the fields of domain-driven design, PaaS platform, and business middle-end technology, and specifically to a method for constructing a domain model process. Background Art

[0002] Currently, in the process of digital transformation, leading KA (KA literally means "key customer" and in Chinese means "important customer" or "important customer"; for supplier companies, KA stores are direct sales terminal platforms with significant advantages in terms of business area, customer flow, and development potential) companies inevitably have many customized requirements. Faced with increasing demands and continuous system iteration, the complex microservices are prone to system corruption and difficult to maintain. The domain-driven design methodology has extraordinary advantages over conventional architectural methods in terms of abstracting business capabilities and decoupling between processing systems. The most important part of domain-driven design is drawing domain model diagrams. Existing technologies have the following shortcomings:

[0003] 1. It is difficult for product developers, architects, test engineers, and business experts to reach a consensus on the technical architecture diagram during the project development process;

[0004] 2. It is difficult for technical solutions to meet requirements and have prototypes, and it is difficult to describe the detailed business rules of the business process;

[0005] 3. The technical solution is not mapped to the code, so it is difficult to guide developers from the code. Coding style, naming style, etc. can only rely on the developer's experience. Summary of the Invention

[0006] The purpose of this application is to provide a method for constructing a domain model process to solve the problems raised in the above background technology, such as it is difficult to reach a consensus during the project development process; it is difficult to describe the detailed business rules of the business process; and it is difficult to guide developers from the code.

[0007] To achieve the above objectives, this application provides the following technical solution: a method for constructing a domain model process, comprising the following steps:

[0008] Step 1: Product Vision Analysis: Users enter the system and publicly express their expectations for the product's target users and core values ​​to prevent deviations from the product's direction. The system also produces a classification of scenarios, business processes, and dependencies between different subdomains to support domain modeling.

[0009] Step 2: Business process diagram, determine the process of user login scenario and generate the corresponding flow chart;

[0010] Step 3: Analyze key business nodes. By analyzing the business process diagram in step 2, we can obtain the key nodes of user operation and system interaction to prepare for building the domain model diagram.

[0011] Step 4: Business rule analysis: Analyze the roles triggered by each user operation command and analyze the internal rules based on each operation command, including event analysis and test case writing;

[0012] Step 5: Command parameter analysis. Commands are key business nodes for front-end access to back-end, so they can be considered as a back-end API. The method name is the command name, and the command parameters come from the prototype and business rules.

[0013] Step 6: Extract domain objects. Specifically, abstract them by command names and determine entities by the unique identifier describing the object in the parameters of each command. After the above operations are completed, extract the entities and then use the rules to reversely infer whether the extracted entities meet the business rules. If not, consider whether to abstract another entity to complete the process.

[0014] Step 7: Determine the aggregate root. The aggregate root is the smallest unit of business boundary, which manages value objects and entities. Clarify the aggregate root by sorting out the relationship between entities and value objects.

[0015] Step 8: Optimize the aggregate root. The specific rules are: if the aggregate occupies too much memory and needs to be split; if the aggregate lock granularity is too large, it will become a concurrency bottleneck and needs to be split; if the aggregate has too many functions and its capabilities are relatively scattered, it needs to be split; if the aggregate function is weak, it is necessary to consider whether it can be merged with other aggregates;

[0016] Step 9: Create views. Track all pages displayed on the prototype. Each page displaying data can be considered a view. Use the business process diagram to deduce and troubleshoot whether additional views are needed to meet the process requirements. Summarize the input and output parameters of all views and look for views that can be merged and shared.

[0017] Step 10: Back-engineering: Based on the domain model diagram, back-engineer the product data or requirement documents to construct the split commands, views, business rules, and business processes. Compare these with the product prototype and requirement documents to see whether they meet the business requirements and business rules defined in the product. At the same time, through rectification, see whether they meet the product vision.

[0018] Step 11: Data model design, design the storage model according to the domain objects in the domain model diagram;

[0019] Step 12: Developers are scored for coding and development design process. Developer coding is guided by the commands, events, domain objects, views, and database tables in the domain model diagram. The naming and parameters of the parameter class must be consistent with the domain model. Figure 1 The development and design process is scored based on the design and development aspects, and the review materials include technical architecture documents, domain model diagrams, and code.

[0020] Step 13: Unify the language. The business and technical parties use a common language to describe business rules and demand changes and reach an agreement with the team.

[0021] Preferably, the method for obtaining the rules in step 4 includes the preconditions for executing the command and the impact on the business after the command is executed.

[0022] Preferably, the event analysis in step 4 is to analyze the domain events that may be triggered after each command is completed. This event is sent after the physical submission of the command, and follows the principle of sending it only when there is a consumer. After the current command is completed, other commands will be triggered. Decoupling operations are performed through events, and views are constructed using domain events as the data source.

[0023] Preferably, the test cases written in step 4 are acceptance criteria for the core business rules, which are used to make the acceptance criteria of this process clearer to everyone and build the business program from the end to the beginning.

[0024] Preferably, the prototype in step 5 is the data that needs to be filled in and displayed on the page operated by the user, and the business rules are the parameters necessary to meet the business rules related to the command.

[0025] Preferably, the domain objects in step 6 include aggregate roots, entities, and value objects.

[0026] Preferably, the relationship between the aggregation and the instruction event in step 7 is defined as: all events are assigned to the aggregation; all command functions can be decomposed into the aggregation for completion; all instructions are assigned to the aggregation or domain service for execution.

[0027] Compared with the prior art, the present invention has the following advantages:

[0028] 1) This application can quickly enable product developers, developer architects, test engineers, and business experts to reach a consensus in the domain modeling process, jointly build the domain model diagram, and quickly implement the idea of ​​domain-driven design and monitor the execution of the entire development process.

[0029] 2) Based on a unified product vision, this application enables business personnel, developers, architects, product managers, and testers to leverage their respective business knowledge to build a domain model diagram that everyone can understand. This diagram then guides development and testing. This methodology allows all roles in the software lifecycle to achieve a high degree of unity in their thinking, using the domain model diagram as a reference and the scoring criteria as a tool for review. This results in a high degree of consistency from business requirements to product design, code development, and test cases. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 This is a schematic diagram of the application process;

[0031] Figure 2 This is a diagram of the business process for user login for this application;

[0032] Figure 3 This is a flowchart of the key business nodes analysis process for this application. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0034] In the description of this application, it should be understood that the terms "upper", "lower", "front", "back", "left", "right", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on this application.

[0035] Example:

[0036] See also Figure 1-3 This application provides a technical solution: a method for constructing a domain model process based on the domain-driven design methodology. A unified language can be input at each node in the entire process. In the following, we use the user login scenario as an example to illustrate the process, which includes the following steps:

[0037] Step 1: Product Vision Analysis: Users enter the system and publicly express their expectations for the product's target users and core values. This helps prevent deviations from the product's direction. The output domain includes a classification of supported scenarios, business processes, and dependencies between different subdomains to support domain modeling. [Example: User login scenario; target users: all users of the system (product managers, developers, architects, test engineers, business experts, system administrators); core values: user login authentication to ensure system security; password reset and modification via email to ensure user account security.]

[0038] Step 2: Business process diagram, determine the process of user login scenario and generate the corresponding flow chart (for the specific scenario process of user login, please refer to Figure 2 );

[0039] Step 3: Business key node analysis, by analyzing the business process diagram in step 2, get the key nodes of user operation and system interaction, and prepare for building the domain model diagram (see Figure 3 );

[0040] Step 4: Business rule analysis: Analyze the roles triggered by each user operation command, and analyze the internal rules based on each operation command. The rules are obtained by including the preconditions for executing the command and the impact on the business after the command is executed. This includes event analysis and writing test cases. Event analysis is to analyze the domain events that may be triggered after each command is completed. This event is sent after the physical submission of the command and follows the principle of only being sent when there is a consumer. After the current command is completed, other commands will be triggered. Operations are decoupled through events, and views are constructed using domain events as the data source. Writing test cases is to set acceptance criteria for core business rules, so that everyone can more clearly understand the acceptance criteria of this process and build business programs from the end to the beginning.

[0041] Example of step 4:

[0042] The business rules under the business node of the new account are: the email address is the unique identifier of the user, and the same email address cannot be registered repeatedly

[0043] Acceptance criteria:

[0044] A. On the registration page, the user enters a new email address. The user successfully registers and enters the login page.

[0045] B. On the registration page, the user enters an existing email address. If the user fails to register, the user is prompted that the email address does not exist.

[0046] Step 5: Command parameter analysis. Commands are key business nodes for front-end access to the back-end, so they can be considered as a back-end API. The method name is the command name, and the command parameters come from the prototype and business rules. The prototype is the data that needs to be filled in when the user operates the page, and the business rules are the parameters required to meet the business rules related to the command.

[0047] Step 6: Extract domain objects. Specifically, abstract them by the name of the command, and determine the entity by the unique identifier describing the object in the parameters of each command. After the above operations are completed, after the entity is extracted, the rules are used to reversely infer whether the extracted entity can meet these business rules. If not, it is necessary to consider whether another entity needs to be abstracted to complete it. Domain objects include aggregate roots, entities, and value objects.

[0048] Step 7: Determine the aggregate root. The aggregate root is the smallest unit of business boundary, which manages value objects and entities. Clarify the aggregate root by sorting out the relationship between entities and value objects.

[0049] Definition of relationships aggregated in command events:

[0050] A. All events are assigned to the aggregate;

[0051] B. All command functions can be decomposed and aggregated;

[0052] C. All instructions are assigned to aggregate or domain services for execution;

[0053] Step 8: Optimize the aggregate root. The specific rules are: if the aggregate occupies too much memory and needs to be split; if the aggregate lock granularity is too large, it will become a concurrency bottleneck and needs to be split; if the aggregate has too many functions and its capabilities are relatively scattered, it needs to be split; if the aggregate function is weak, it is necessary to consider whether it can be merged with other aggregates;

[0054] Step 9: Create views. Track all pages displayed on the prototype. Each page displaying data can be considered a view. Use the business process diagram to deduce and troubleshoot whether additional views are needed to meet the process requirements. Summarize the input and output parameters of all views and look for views that can be merged and shared.

[0055] Step 10: Back-engineering: Based on the domain model diagram, back-engineer the product data or requirement documents to construct the split commands, views, business rules, and business processes. Compare these with the product prototype and requirement documents to see whether they meet the business requirements and business rules defined in the product. At the same time, through rectification, see whether they meet the product vision.

[0056] Step 11: Data model design, design the storage model according to the domain objects in the domain model diagram;

[0057] Step 12: Developers are scored for coding and development design process. Developer coding is guided by the commands, events, domain objects, views, and database tables in the domain model diagram. The naming and parameters of the parameter class must be consistent with the domain model. Figure 1 In the same way, developers use business rules to guide the writing of specific business logic code. The development and design process is scored by reviewing the design and development aspects, and the review materials include technical architecture documents, domain model diagrams, and code.

[0058] Step 13: Unify the language. The business and technical parties use a common language to describe business rules and demand changes and reach an agreement with the team.

[0059] The definition rules for language unification in step 13 are:

[0060] 1. During domain modeling, we often need to establish a commonly agreed-upon glossary in the document;

[0061] 2. A unified language runs through the entire process of product requirements, architecture design, code writing, testing, and acceptance;

[0062] 3. A unified language cannot have ambiguity within the same scope;

[0063] 4. When maintaining a domain terminology table, you must provide the corresponding English terms, otherwise it may directly affect the code implementation;

[0064] 5. Provide specific examples for difficult-to-understand terms.

[0065] The following table is a scoring template for the design process developed in step 12.

[0066]

[0067]

[0068]

[0069] The following table is an example of the user unified language in step 13.

[0070]

[0071]

[0072]

[0073]

[0074] The above shows and describes the basic principles, main features and advantages of the present application. For those skilled in the art, it is obvious that the present application is not limited to the details of the above exemplary embodiments, and the present application can be implemented in other specific forms without departing from the spirit or basic features of the present application; therefore, no matter from which point of view, the embodiments should be regarded as exemplary and non-restrictive. The scope of the present application is limited by the appended claims rather than the above description. Therefore, it is intended that all changes that fall within the meaning and scope of the equivalent elements of the claims are included in the present application, and any figure marks in the claims should not be regarded as limiting the claims involved.

[0075] Although the embodiments of the present application have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations may be made to these embodiments without departing from the principles and spirit of the present application, and the scope of the present application is defined by the appended claims and their equivalents.

Claims

1. A method for constructing a domain model process, characterized by: The following steps are involved: Step 1: Product Vision Analysis: Users enter the system and publicly express their expectations for the product's target users and core values ​​to prevent deviations from the product's direction. The system also produces a classification of scenarios, business processes, and dependencies between different subdomains to support domain modeling. Step 2: Business process diagram, determine the process of user login scenario and generate the corresponding flow chart; Step 3: Analyze key business nodes. By analyzing the business process diagram in step 2, we can obtain the key nodes of user operation and system interaction to prepare for building the domain model diagram. Step 4: Business rule analysis: Analyze the roles triggered by each user operation command and analyze the internal rules based on each operation command, including event analysis and test case writing; Step 5: Command parameter analysis. The command is a key business node for the front-end to access the back-end. The command is a back-end API, where the method name is the command name, and the command parameters are derived from the prototype and business rules. Step 6: Extract domain objects. Specifically, abstract them by command names and determine entities by the unique identifier describing the object in the parameters of each command. After the above operations are completed, extract the entities and then use the rules to reversely infer whether the extracted entities meet the business rules. If not, consider whether to abstract another entity to complete the process. Step 7: Determine the aggregate root. The aggregate root is the smallest unit of business boundary, which manages value objects and entities. Clarify the aggregate root by sorting out the relationship between entities and value objects. Step 8: Optimize aggregate roots. The specific rules are: if the aggregate occupies too much memory, it needs to be split; if the aggregate lock granularity is too large, it will become a concurrency bottleneck and needs to be split; if the aggregate has too many functions and its capabilities are relatively scattered, it needs to be split; The aggregation function is weak, so you need to consider whether to merge it with other aggregate roots; Step 9: Create views. Track all pages displayed on the prototype. Each page displaying data is a view. Use the business process diagram to deduce and troubleshoot whether additional views are needed to meet the process requirements. Summarize the input and output parameters of all views and look for views that can be merged and shared. Step 10: Back-engineering: Based on the domain model diagram, back-engineer the product data or requirement documents to construct the split commands, views, business rules, and business processes. Compare these with the product prototype and requirement documents to see whether they meet the business requirements and business rules defined in the product. At the same time, through rectification, see whether they meet the product vision. Step 11: Data model design, design the storage model according to the domain objects in the domain model diagram; Step 12: Developers are scored for their coding and development design process. Developer coding involves guiding the coding based on the commands, events, domain objects, views, and database tables in the domain model diagram. The naming and parameters of the parameter classes must be exactly the same as those in the domain model diagram. The development design process is scored by reviewing the design and development aspects, and the review materials include the technical architecture document, domain model diagram, and code. Step 13: Unify the language. The business and technical teams use a common language to describe business rules and requirement changes, and reach consensus with the team. The event analysis in step 4 is to analyze the domain events that may be triggered after each command is completed. This event is sent after the physical submission of the command, following the principle of sending it only when there is a consumer. After the current command is completed, other commands will be triggered. Decoupling operations are performed through events, and views are constructed using domain events as the data source.

2. The method for constructing a domain model process according to claim 1, characterized in that: The method for obtaining the rules in step 4 includes the preconditions for executing the command and the impact on the business after the command is executed.

3. The method for constructing a domain model process according to claim 1, characterized in that: The test cases written in step 4 are acceptance criteria for the core business rules, which are used to make the acceptance criteria of this process clearer to everyone and build the business program from the end to the beginning.

4. The method for constructing a domain model process according to claim 1, wherein: In step 5, the prototype is the data that needs to be filled in and displayed on the page operated by the user, and the business rules are the parameters necessary to meet the business rules related to the command.

5. The method for constructing a domain model process according to claim 1, wherein: The domain objects in step 6 include aggregate roots, entities, and value objects.

6. The method for constructing a domain model process according to claim 1, wherein: The relationship between the aggregate and the instruction event in step 7 is defined as: all events will be assigned to the aggregate; all command functions can be decomposed into aggregates for completion; all instructions are assigned to aggregates or domain services for execution.

Images