A backend service construction method, system and device based on multi-service model fusion and a storage medium

Abstract

The application discloses a backend service construction method, system and device based on multi-service model fusion and a storage medium. The method comprises the following steps: acquiring at least two service models; converting the service models into intermediate representations with unified semantic labels; performing difference detection on the intermediate representations to identify semantic conflicts, data conflicts and / or behavior conflicts; automatically resolving the conflicts based on a conflict resolution rule library, and calling a large language model to assist in generating a resolution scheme for a conflict type that is not covered by the rule library; constructing a fusion graph based on the resolved service models; and generating the code of the backend service based on the fusion graph. The application is used for the rapid construction of enterprise-level backend services.

Description

Technical Field

[0001] This invention relates to the field of computer software development technology, specifically to a method, system, device, and storage medium for building backend services based on the integration of multiple business models, and is particularly suitable for scenarios in enterprise application development that require the integration of multiple business domain models for unified backend service construction. Background Technology

[0002] As enterprises deepen their digital transformation, the complexity of backend service development is increasing daily. A typical enterprise application often involves multiple business domains—user management, order processing, inventory management, payment settlement, logistics and delivery, etc.—each with its own independent business model. Traditional development methods require separate modeling and coding for each business domain, which not only results in long development cycles but also makes it difficult to guarantee data and logical consistency between business domains.

[0003] In recent years, various technical approaches have emerged in the industry to improve software development efficiency.

[0004] One approach is model-driven development. Tencent Technology (Shenzhen) Co., Ltd., in its invention patent application (publication number CN117406980A) filed in July 2022, proposed a model-driven development method. This method constructs a model architecture by assembling visual model elements and generates corresponding modeling tools and code generators based on this architecture. This solution, tailored to different application scenarios, can construct corresponding model architectures by assembling visual model elements and generate modeling tools and code generators based on the constructed model architecture, thereby automatically building business models and generating business code. However, the core of this solution lies in constructing a single business model for a single application scenario. When facing complex scenarios involving multiple business domains simultaneously, there is a lack of collaborative integration mechanisms between different business models; each model remains independent and difficult to process collaboratively in a unified manner.

[0005] Another approach is code generation based on a microservices architecture. Qianjin Network Information Technology (Shanghai) Co., Ltd., in its invention patent application (publication number CN118747068A) filed in July 2024, proposed a code generation method based on a microservices architecture. This method establishes a database based on the data tables configured in the business system, uses table fields as metadata to establish a mapping relationship between them and class attributes in Java entity classes, and then combines this with microservices architecture template information to generate backend code. This solution can improve code generation efficiency to some extent, but its essence is "data table-driven" rather than "business model-driven"—the generated code mainly focuses on routine data operations in the entity layer and data access layer, while complex business logic in the service layer still needs to be manually written by developers. Furthermore, this method relies on data tables as the sole input source and cannot handle the needs of the business logic design phase before tables have been created.

[0006] Another approach is intelligent code generation based on large language models. Guangdong XinZhongWang Information Technology Co., Ltd., in its invention patent application filed in May 2024 (authorization announcement number CN118276829B), proposed an intelligent agile software development method based on large language models. This method determines key front-end information, business logic information, and business process information based on user development requirements, generating front-end component code, back-end service code, and development documentation respectively. This solution introduces large language models into the software development process, exploring their application in code generation. However, its technical solution essentially converts user requirement descriptions directly into code—the input is a natural language description of the requirements, and the output is the corresponding code snippet. This approach has two shortcomings: first, the stability and controllability of code generated by large language models are insufficient; the same requirement may result in significantly different code in different generation iterations; second, when the collaborative logic of multiple business models is involved, relying solely on natural language descriptions is insufficient to accurately convey the complex dependencies and conflict constraints between models.

[0007] In addition to the three main technical routes mentioned above, there have also been related explorations in the low-code / no-code field. Zhongke Jiuzhou Technology Co., Ltd., in its invention patent application filed in September 2025 (publication number CN121209859A), proposed a no-code application construction method based on a multi-level business model. This method receives user business requirements and extracts requirement feature tags, matches them with a multi-level business model set in a business model library, and outputs application components after parsing and instantiation by a generation engine. This solution has application value in no-code application construction scenarios, but its "multi-level business model" refers to models at different abstraction levels within the same business domain (such as multi-level refinement from requirement model to design model to implementation model), rather than the "fusion between business models from multiple different business domains" that this invention focuses on.

[0008] In summary, existing technologies generally have the following shortcomings: First, there is a lack of a collaborative integration mechanism for multiple business models. Whether it is Tencent's model-driven development solution or Zhongke Jiuzhou's multi-level business model solution, their core is to model around "single business domain" or "different abstraction levels of the same business domain". When faced with complex scenarios involving multiple independent business domains such as users, orders, inventory, and payment, the relationships, data flow and call sequence between the various business models cannot be systematically described and utilized.

[0009] Second, code generation remains superficial. Qianjin Networks' solution can only generate entity layer and data access layer code based on data table structures; the business logic of the service layer still needs to be written manually. Although Guangdong XinZhongWang's solution can generate service layer code by using large language models, its generation process lacks a systematic understanding of the relationships between business models, making it difficult to guarantee the quality of the generated code when multi-model collaborative logic is involved.

[0010] Third, there is a lack of systematic handling of model conflicts. When multiple business models coexist, the definitions of the same concept may differ between models (for example, "user status" has different meanings in the user management model and the order model), or there may be differences in the field definitions of the same data object, or the processing logic for the same business operation may be contradictory. Currently, there is no systematic solution for detecting and automatically resolving semantic, data, and behavioral conflicts between multiple business models.

[0011] Fourth, model changes are costly. In existing model-driven development solutions, once the business model changes, it is usually necessary to regenerate all the code, resulting in low efficiency in model iteration. For enterprise applications that need to frequently respond to business changes, this is a significant pain point.

[0012] To address the aforementioned issues, this invention proposes a method, system, device, and storage medium for constructing backend services based on the fusion of multiple business models. Summary of the Invention

[0013] 1. Technical problem to be solved: The technical problem to be solved by this invention is that the existing technology lacks a mechanism for systematically integrating business models from multiple different business domains, resulting in low efficiency in the development of backend services across business domains, and the inability to automatically detect and resolve conflicts between multiple business models.

[0014] 2. Technical Solution: To solve the above problems, the present invention adopts the following technical solution.

[0015] This invention provides a method for building backend services based on the fusion of multiple business models, the method comprising the following steps: S1: Obtain multiple business models.

[0016] Obtain at least two business models. Each business model contains entity definitions, attribute definitions, operation definitions, and constraint definitions. These business models can come from different business domains, such as business models from the user management domain, order management domain, inventory management domain, payment management domain, etc. Business models can use Unified Modeling Language class diagrams, entity relationship diagrams, JSON Schema, or other structured description formats.

[0017] S2: Unified semantic representation.

[0018] Each business model is converted into an intermediate representation with unified semantic tags. Semantic tags are used to identify the semantic type and attributes of each element. For example, the tag "Business Entity" indicates that the element is a business entity, the tag "Aggregate Root" indicates an aggregate root, the tag "Value Object" indicates a value object, and the tag "Business Rule" indicates a business rule, etc. Through unified semantic tags, elements with similar meanings in different business models can be identified and compared by the system.

[0019] S3: Difference detection and conflict identification.

[0020] Difference detection is performed on the transformed intermediate representation to identify three types of conflicts between the various business models: Semantic conflict: Elements in different business models that have the same or belong to the same pre-defined semantic category have different definitions. For example, in the user management model, the value of "user status" is "normal, frozen, canceled", while in the order model, the value of "user status" is "active, inactive". The two have similar meanings but different sets of values.

[0021] Data conflict: Inconsistent field definitions for the same data object in different business models. For example, the "Order Amount" field in the order model is a high-precision numeric type, while the "Order Amount" field in the financial model is a double-precision floating-point type.

[0022] Behavioral conflicts: There are contradictions in the processing logic or constraints of the same business operation in different business models. For example, in the order model, the "cancel order" operation can be executed at any time after the order is generated, while in the inventory model, the inventory release operation associated with "cancel order" can only be executed under specific conditions.

[0023] S4: Adaptive conflict resolution.

[0024] The system automatically resolves identified conflicts based on a pre-defined conflict resolution rule base. This rule base predefines resolution strategies for common conflict types, such as type compatibility conversion rules (automatically converting double-precision floating-point types to high-precision numeric types), naming convention rules (unifying underscore and camelCase naming to the system default style), and field merging rules.

[0025] For complex conflict types not covered in the rule base, the system automatically constructs prompt words containing the conflict type and content, sends these prompt words to a large language model, receives the resolution strategy returned by the large language model, and converts the resolution strategy into an executable resolution solution, which is then output to the user for confirmation. After user confirmation, the resolution solution is added to the conflict resolution rule base, enabling continuous expansion of the rule base.

[0026] S5: Construct a fusion graph.

[0027] Based on the unified model after decomposition, a multi-business model fusion graph is constructed. The fusion graph is presented in the form of a directed graph: entities in each business model are nodes, and the relationships between entities are edges. The graph marks the data flow and / or call sequence corresponding to each relationship. The fusion graph can output visual information for developers to review and confirm.

[0028] S6: Generate backend service code based on the fused graph.

[0029] The backend service layered code is automatically generated based on the fusion graph, including: Entity layer code: generated based on entity nodes in the fusion graph, with each entity node corresponding to an entity class.

[0030] Data transmission object layer code: Generate corresponding data transmission object classes according to the boundaries of each business model.

[0031] Data access layer code: generated based on the relationships between entities in the fusion graph, including basic data operations and complex query methods generated based on the relationships.

[0032] Business logic layer code: Generated based on the relationships and call sequence in the fusion graph. Specifically, the execution order of each business operation is determined according to the call sequence in the fusion graph, the data dependencies between each business operation are determined according to the data flow, and service orchestration code is automatically generated based on the execution order and data dependencies. This layer also includes transaction management code, exception handling code, and / or compensation mechanism code.

[0033] Interface layer code: Generates application programming interfaces that conform to the expressive state passing specification based on the business logic layer code, and automatically generates interface documentation.

[0034] S7: Incremental code evolution.

[0035] When any business model changes, the system automatically determines the content of the change, then identifies the affected entity nodes in the fusion graph based on the change content. Starting from these entity nodes, the system traverses the fusion graph according to adjacency relationships and propagation paths to obtain the change's impact domain. The change's impact domain includes the affected entities, relationships, and / or code files. The system only incrementally regenerates the code within the change's impact domain; unaffected code (including manual modifications by developers) is retained.

[0036] S8: Automatic generation of microservice architecture.

[0037] Based on the fused graph, the system can also perform cluster analysis to identify the coupling degree between entities and divide entities into at least two candidate microservices according to the coupling degree. Entities with coupling degrees exceeding a preset threshold are assigned to the same candidate microservice, while entities with coupling degrees below the preset threshold are assigned to different candidate microservices. This partitioning process can be implemented based on the bounded context identification rules in Domain-Driven Design. After partitioning, the system automatically generates service boundary definitions for each candidate microservice and inter-service communication contracts, and generates containerized deployment description files based on the partitioning results.

[0038] The present invention also provides a backend service construction system based on multi-business model fusion, including a model acquisition module, a model conversion module, a conflict detection module, a conflict resolution module, a graph construction module, and a code generation module, each module being used to implement the corresponding steps in the above method.

[0039] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0040] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0041] 3. Beneficial effects: Compared with the prior art, the technical solution provided by this invention has the following advantages: (1) Achieved systematic integration of multiple business models: By constructing a unified semantic tagging system and fusion graph, the models that were originally scattered in different business domains were integrated into an organic whole, so that the relationship between the various business models, the data flow and the call sequence can be clearly expressed and utilized. This is an important breakthrough for the existing model-driven development solution - the latter only supports the construction and code generation of a single business model and cannot handle the scenario of multi-business model collaboration.

[0042] (2) It fills the gap in multi-model conflict handling: There is no systematic detection and resolution scheme for semantic conflicts, data conflicts and behavioral conflicts between multiple business models in the existing technology. The present invention realizes automatic detection, intelligent resolution and continuous expansion of the rule base through a two-layer resolution architecture of rule engine and large language model collaboration, which ensures the consistency of multi-business model integration from the source.

[0043] (3) Automated generation of code from model to full stack: Unlike existing solutions that can only generate entity layer and data access layer code based on data tables, this invention can automatically generate complete layered code from the entity layer to the interface layer based on the fusion graph, especially the business logic orchestration code of the service layer—this part of the code usually needs to be written manually by developers in existing technologies. It also differs from solutions that simply rely on large language models to generate code. This invention uses the fusion graph as the deterministic basis for code generation, and the large language model is only used as an auxiliary means of conflict resolution, ensuring the stability and controllability of the generated code.

[0044] (4) Significantly reduced cost of model changes: Through the incremental code evolution mechanism, changes to the business model only trigger the regeneration of code within the affected scope, rather than a full rebuild. This enables model-driven development to truly possess agile iteration capabilities and quickly respond to changes in business requirements.

[0045] (5) Automatic derivation from business model to microservice architecture is realized: microservice splitting scheme and containerized deployment description file are automatically generated based on the clustering analysis results of the fusion graph, expanding the boundary of code generation from "single application" to "distributed microservice system", and automating the entire process from business model input to deployable system delivery for developers.

[0046] It should be noted that the structures not described in this invention are not related to the design points and improvement directions of this invention, and are the same as or can be implemented using existing technologies, so they will not be elaborated here. Attached Figure Description

[0047] Figure 1 A schematic diagram of the overall process of the backend service construction method based on multi-business model fusion provided in the embodiments of the present invention; Figure 2 A schematic diagram illustrating the process of unified semantic representation and difference detection for multi-service models provided in this embodiment of the invention; Figure 3 This is a schematic diagram of the conflict adaptive resolution process provided in an embodiment of the present invention; Figure 4 A schematic diagram of the multi-service model fusion map provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a code generation architecture based on a fusion graph provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the incremental code evolution process provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of automatic microservice partitioning based on fusion graph provided in an embodiment of the present invention. Detailed Implementation

[0048] To facilitate understanding of the present invention, a more complete description of the invention will be given below with reference to the accompanying drawings, which illustrate several embodiments of the invention. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of the invention will be more thorough and complete.

[0049] In the following specific implementation, some terms will be explained first for ease of understanding.

[0050] "User" represents the core business object in the user management domain; "Order" represents the core business object in the order management domain; and "Inventory" represents the core business object in the inventory management domain.

[0051] The “@” symbol represents annotations in a program. For example, “@Service” represents a service layer annotation, used to identify that a class belongs to a service layer component; “@Transactional” represents a transaction annotation, used to identify that a method or class requires transaction management support; “@Entity” represents an entity annotation, used to identify that a class belongs to a data entity class; and “@Id” represents a primary key annotation, used to identify the primary key field in an entity class.

[0052] The "→" symbol is used to indicate the direction of data flow or call sequence.

[0053] "@BusinessEntity" represents the business entity label, "@AggregateRoot" represents the aggregate root label, "@BusinessField" represents the business field label, "@EntityId" represents the entity identifier label, and "@ForeignKey" represents the foreign key label.

[0054] "DTO" stands for Data Transfer Object, used to transfer data between different layers of the system. "DAO" stands for Data Access Object, used to encapsulate access operations to a data source. "Repository" represents the repository pattern, a design pattern for the data access layer.

[0055] "JSON Schema" refers to a data model description specification based on the JSON format. "UML" stands for Unified Modeling Language.

[0056] "OpenAPI" refers to a specification format for describing application programming interfaces. "RESTful" refers to a descriptive state delivery style.

[0057] "Feign" refers to a declarative hypertext transfer protocol client, which is often used for inter-service calls in microservice architectures.

[0058] "Dockerfile" refers to a description file used to build a Docker container image. "Kubernetes" refers to a container orchestration platform.

[0059] The above terms are used in the following embodiments and will not be explained again. Example 1

[0060] This embodiment uses the construction of a backend service for an e-commerce system as an example to describe the method of the present invention in detail. This e-commerce system involves three business domains: user management, order management, and inventory management.

[0061] First, obtain the business models for the three business domains.

[0062] The business model of the user management domain includes a user entity, which has attributes such as user ID (userId), user name (userName), status (status), and registration time (registerTime). The status field has values ​​of "normal," "frozen," and "deactivated." The user management domain also includes operations such as user registration, user freezing, and user unfreezing.

[0063] The business model of the order management domain includes the Order entity, which has attributes such as order ID (orderId), user ID (userId), order amount (orderAmount), order status (orderStatus), and creation time (createTime). The order status field has values ​​of "Pending Payment," "Paid," "Cancelled," and "Completed." The order management domain also includes operations such as creating orders, canceling orders, and paying for orders.

[0064] The business model of the inventory management domain includes the inventory entity, which has attributes such as inventory unit identifier (skuId), quantity, and reserved quantity. The inventory management domain also includes operations such as reserving inventory, releasing inventory, and deducting inventory.

[0065] The three business models mentioned above can be input into the system in the form of Unified Modeling Language (UML) class diagrams or in the form of JSON Schema files. The system supports multiple input formats, including XMI export files of UML models, JSON Schema files conforming to specific specifications, and model definition files constructed by users through a graphical interface.

[0066] Subsequently, the system converts each business model into an intermediate representation with unified semantic tags.

[0067] Specifically, for the User entity, the system adds a "Business Entity" and "Aggregate Root" tag, a "Entity Identifier" tag to its user ID (userId) attribute, and a "Business Field" tag to other attributes. For the Order entity, the system similarly adds a "Business Entity" and "Aggregate Root" tag, and a "Foreign Key" tag to its user ID (userId) attribute—this tag indicates that the field references the primary key of the User entity, allowing the system to identify the relationship between Order and User. For the Inventory entity, the system adds a "Business Entity" tag and a "Entity Identifier" tag to its inventory unit identifier (skuId) attribute.

[0068] The unified semantic tag system is predefined in the system's tag library, and users can also customize new tag types according to their actual business needs.

[0069] Next, the system performs difference detection on the intermediate representations of the three business models.

[0070] In terms of semantic conflict detection, the system extracts the semantic tags of each element in each business model and compares elements in different business models that have the same or belong to the same preset semantic category. In this embodiment, the system detected that: in the user management model, the "status" field of the User entity means the user account status, with values ​​of "normal," "frozen," and "cancelled"; while in the order management model, the "userstatus" field of the Order entity means the user's active status in the current order period, with values ​​of "active" and "inactive." Both fields have the semantic tag "user status," but their definitions and value sets are completely different, leading the system to determine this as a semantic conflict.

[0071] Regarding data conflict detection, the system detected that the "orderAmount" field of the Order entity in the order management model is a double-precision floating-point type, while if a financial model also exists in the system (not actually input in this embodiment), the corresponding amount field in the financial model may use a high-precision numeric type. The difference in precision between the two numeric types is considered a data conflict by the system.

[0072] Regarding behavioral conflict detection, the system detected the following: In the order management model, the business rule for the "cancel order" operation allows cancellation as long as the order status is not "completed"; however, in the inventory management model, the business rule for the "release inventory" operation only allows the release of reserved inventory when the order status is "pending payment" or "paid." These two operations present a logical contradiction in the "cancel order" business scenario—if the order status is "cancelled," this status is valid according to the order model's rules, but according to the inventory model's rules, the conditions for releasing inventory cannot be met in this situation. The system identifies this as a behavioral conflict.

[0073] The system presents the detection results of the above three types of conflicts to the user in a list format and records detailed information for each conflict, including the conflict type, the business model and specific elements involved, and a detailed description of the conflict, providing a basis for subsequent resolution steps.

[0074] Then, the system adaptively resolves the identified conflicts.

[0075] For conflicts of defined rule types in the conflict resolution rule base, the system automatically resolves them by invoking the corresponding resolution rule. For example, the system's preset type compatibility rule stipulates that when a data conflict between a double-precision floating-point type and a high-precision numeric type is detected, the double-precision floating-point type is automatically converted to a high-precision numeric type. In this embodiment, for a type conflict in the "Order Amount" field of the Order entity, the system invokes this rule to automatically complete the type conversion.

[0076] For complex conflict types not covered by the rule base, the system invokes a large language model for assisted resolution. Specifically, the system automatically constructs a prompt word containing the conflict type (semantic or behavioral conflict), the name and specific elements of the business model involved, the definition and value set of each element in the current model, a detailed description of the conflict, and an instruction to request a resolution suggestion from the large language model. For example, for the semantic conflict mentioned above, the system-constructed prompt word describes: The user management model has a status field for the User entity, defined as the user account status, with values ​​of normal, frozen, and canceled; the order management model has a user status field for the Order entity, defined as the user's active status within the current order period, with values ​​of active and inactive; the two fields have the same semantic label "user status," but their definitions and values ​​are different, please provide a resolution suggestion.

[0077] The system sends the prompt words to a large language model and receives the resolution strategy returned by the model. Possible resolution suggestions from the large language model include: unifying the two fields into a single field "User Status," expanding the value set to "Normal, Frozen, Logout, Active, Inactive," and specifying the meaning of each value in different business scenarios in the field description; or retaining two separate fields but renaming them "Account Status" and "Order Activity Status" respectively to eliminate ambiguity.

[0078] The system converts the conflict resolution strategies returned by the large language model into structured conflict resolution solutions and outputs them to the user for confirmation. The user can choose to accept, modify, or reject the solution based on actual business needs. After user confirmation, the conflict resolution solution is added to the conflict resolution rule base, and the system can automatically call it when similar conflicts occur in the future. Example 2

[0079] This embodiment continues to use the e-commerce system in Embodiment 1 as an example to illustrate the construction process of the fusion graph and the code generation process based on the fusion graph.

[0080] After resolving the conflicts, the system constructs a multi-service model fusion graph based on the unified model after the conflicts are resolved.

[0081] Specifically, the system uses all entities in the three business models as nodes: User, Order, and Inventory. Then, the system constructs edges based on the relationships between entities: the userId field in the Order entity references the userId primary key in the User entity, thus establishing a directed edge from Order to User, labeled as "Order depends on user information"; order creation triggers inventory reservation and deduction, thus establishing a directed edge from Order to Inventory, labeled as "Create order → Reserve inventory → Deduct inventory"; order cancellation triggers inventory release, thus establishing another directed edge from Order to Inventory, labeled as "Cancel order → Release inventory".

[0082] The system outputs the completed fusion graph in a visual format. Developers can view the graph through a graphical interface to confirm whether the relationships between entities, data flow, and call sequence meet business expectations. The visualized graph supports interactive operations such as zooming, dragging, and node highlighting, making it easy for developers to quickly locate areas of interest in a large-scale graph. In this embodiment, developers can clearly see through the visualized graph that a complete "user order placement" business process involves the collaboration of three entities: User, Order, and Inventory. Data flows from user information to order information and then to inventory information, with the call sequence being "verify user status → create order → reserve inventory → deduct inventory → update order status".

[0083] Subsequently, the system automatically generates layered code for backend services based on the fused graph.

[0084] At the entity layer, the system generates corresponding entity classes based on the User node in the fusion graph. These classes include attributes such as user identifier, user name, status, and registration time, and are annotated with relevant entity and table mapping annotations. Similarly, the system generates corresponding entity classes based on the Order and Inventory nodes.

[0085] At the data access layer, based on the relationship between orders and users in the fusion graph, the system automatically generates a method in the order data access interface to query the order list by user identifier. Based on the relationship between orders and inventory, the system automatically generates a method in the inventory data access interface to query inventory reservation records by order identifier.

[0086] At the business logic layer, the system automatically generates business logic orchestration code based on the call sequence and data flow in the fusion graph. Taking the "user placing an order" business process as an example, the fusion graph records the call sequence as "verify user status → create order → reserve inventory → deduct inventory → update order status," and the data flow as user ID (userId) → order ID (userId) → inventory unit ID (skuId). Based on the above information, the system automatically generates the following business logic: First, it queries and verifies whether the user status is "normal" or "active" based on the user ID; if the status is abnormal, it throws a business exception. Then, it creates an order, sets the order ID, user ID, order amount, order status as "pending payment," and creation time, and saves the order. Next, it sequentially calls the reserve inventory and deduct inventory operations. Finally, it updates the order status to "paid" and saves the transaction. The entire process is placed within a transaction; if any step encounters an exception, it automatically rolls back, and if the inventory operation fails, it automatically updates the order status to "cancelled" as compensation.

[0087] The execution order, transaction boundaries, exception handling, and compensation mechanisms in the above business logic are all automatically generated based on the fusion graph, and developers do not need to write them manually.

[0088] At the interface layer, the system automatically generates application programming interfaces (APIs) conforming to the expressive state passing style based on the business logic layer, including the interface's request path, request method, request parameters, and response format. Simultaneously, the system automatically generates OpenAPI-formatted API documentation, containing a complete description of each interface. Example 3

[0089] This example illustrates how the system performs incremental code evolution when the business model changes.

[0090] Suppose that after the system has been running for a period of time, business requirements change: in the business model of the order management domain, the order entity needs to add a "delivery address" field.

[0091] First, the system detected a change to the Order entity – a new attribute, "delivery address," of type string, was added.

[0092] Then, starting with the Order entity node, the system searches for related entities in the fusion graph that are associated with Order. Since Order is associated with User through the userId field, the User entity is affected; because order creation and cancellation are related to inventory operations in a sequential manner, the Inventory entity is also affected. The system defines the Order, User, and Inventory entities, along with their relationships, as the model-level impact scope of the change's impact domain.

[0093] Furthermore, the system maps the impact from the model level to the code file level: changes to the Order entity directly affect the Order entity class code, the Order data access interface code, the methods involving order creation in the order business logic, and the interfaces involving order creation in the order interface layer. Since User and Inventory are associated with Order, but this change only involves adding fields to Order and does not alter the definitions of User and Inventory themselves, the entity class code for User and Inventory is unaffected. However, the calling code in the order business logic involving User and Inventory may need adjustment—for example, when creating an order, the delivery address needs to be passed to the inventory service for calculating shipping costs.

[0094] The system only regenerates the code within the affected domain of the above changes: The order entity class is regenerated, adding a "delivery address" field and its acquisition and setting methods; the "create order" method in the order business logic is regenerated, setting the "delivery address" field when creating the order; the data transfer object class for the order creation request is regenerated, adding the "delivery address" field. Methods in the user entity class, inventory entity class, and order data access interface that do not involve the added field, as well as the interface definition of the order interface layer, remain unchanged.

[0095] Manual modifications made to the code by developers (such as custom validation rules added in the order business logic) are retained during incremental generation and will not be overwritten. Example 4

[0096] This embodiment illustrates how the system automatically generates a microservice architecture scheme based on the fusion graph.

[0097] Based on the fused graph, the system performs cluster analysis on the entities in the graph and calculates the coupling degree between each entity. The calculation of coupling degree takes into account the following factors: whether there is a direct relationship between entities (if there is a foreign key relationship, the coupling degree is high), the frequency of calls between entities in business logic (if there is frequent collaboration, the coupling degree is high), and whether there is a bidirectional data dependency between entities (if there is, the coupling degree is high).

[0098] In this embodiment, the system calculates that: the coupling between users and orders is high because orders depend on user information, and changes in user information will affect order queries; the coupling between orders and inventory is high because the creation and cancellation of orders directly affect inventory; and the coupling between users and inventory is low because there is no direct business relationship between users and inventory.

[0099] Based on the coupling analysis results, the system partitions microservices according to the bounded context identification rules in Domain-Driven Design: Users and Orders are assigned to the same candidate microservice, named "User Order Service"; Inventory is assigned to a separate candidate microservice, named "Inventory Service". The system also generates service boundary definitions for each candidate microservice, clearly defining the entities and business operation scope responsible for each microservice.

[0100] After the partitioning is completed, the system automatically generates inter-service communication contracts, including the interface definition for the "user order service" to call the "inventory service", the communication protocol (Hypertext Transfer Protocol / representational state transfer or gRPC) and serialization method (JSON or Protobuf), as well as the configuration information for service discovery and load balancing.

[0101] Finally, the system automatically generates containerized deployment description files based on the microservice partitioning results, including Dockerfile for each microservice, container orchestration files (such as docker-compose.yml or Kubernetes Deployment and Service orchestration files), and network policies and configuration files between services.

[0102] Thus, starting from three independent business model inputs, and going through unified semantic representation, conflict detection and resolution, fusion graph construction, code generation, incremental evolution support, and automatic partitioning of microservice architecture and generation of containerized deployment description files, the entire backend service is automatically built from model to deployable system. Example 5

[0103] This embodiment describes the backend service construction system based on the fusion of multiple business models provided by the present invention.

[0104] The system includes the following modules: The model acquisition module is used to acquire at least two business models. This module supports multiple input formats, including Unified Modeling Language (UML) model XMI files, JSON Schema files, and model definitions constructed by users through a graphical interface.

[0105] The model conversion module is used to convert various business models into intermediate representations with unified semantic tags. This module has a built-in semantic tag library and supports user-defined tags.

[0106] The conflict detection module is used to perform difference detection on the intermediate representation and identify semantic conflicts, data conflicts and / or behavioral conflicts between various business models.

[0107] The conflict resolution module is used to automatically resolve identified conflicts based on a pre-built conflict resolution rule base. This module further includes a rule resolution unit (for automatically resolving conflicts of existing rule types in the rule base), a model resolution unit (for generating resolution solutions by calling a large language model for conflicts not covered in the rule base), and a confirmation interaction unit (for outputting the resolution solution to the user for confirmation and updating the rule base).

[0108] The graph construction module is used to build a fused graph based on the decomposed business models. This module includes a graph database or in-memory graph structure for storing and querying graph data, and provides a visualization output interface.

[0109] The code generation module is used to generate backend service code based on the fusion graph. This module further includes an entity layer generation unit, a data transmission object layer generation unit, a data access layer generation unit, a business logic layer generation unit, and an interface layer generation unit.

[0110] The system may also optionally include a change management module and a microservice generation module. The change management module includes a change detection unit, an impact domain calculation unit, and an incremental generation unit, used to implement incremental code evolution after business model changes. The microservice generation module includes a clustering analysis unit, a microservice partitioning unit, and a contract generation unit, used to automatically generate microservice architecture solutions based on the fusion graph.

[0111] The modules mentioned above can be deployed on the same computing device or distributed across multiple computing devices, and the modules communicate with each other through data interfaces. Example 6

[0112] This embodiment describes the computer device and computer-readable storage medium provided by the present invention.

[0113] The present invention also provides a computer device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in any of the above method embodiments.

[0114] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in any of the above method embodiments. The computer-readable storage medium can be any tangible medium containing or storing a program, including but not limited to: USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0115] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for constructing backend services based on the fusion of multiple business models, characterized in that, include: Obtain multiple business models, each of which includes entity definitions, attribute definitions, operation definitions, and constraint definitions; Each business model is converted into an intermediate representation with a unified semantic tag, which is used to identify the semantic type and attributes of each element; Perform difference detection on the intermediate representation to identify semantic conflicts, data conflicts and / or behavioral conflicts between the various business models; The identified conflicts are automatically resolved based on a predefined conflict resolution rule base, and for conflict types not covered by the conflict resolution rule base, a large language model is invoked to assist in generating a resolution scheme. A fusion graph is constructed based on the resolved intermediate representation. The fusion graph is used to characterize the relationships, data flow and / or call sequence between entities contained in each of the business models. Based on the fusion graph, layered code for the backend service is generated according to a preset layering strategy. The layered code includes entity layer code, data access layer code, business logic layer code, and interface layer code.

2. The method according to claim 1, characterized in that, The difference detection includes: Extract semantic tags from each element in each of the aforementioned business models; Compare elements in different business models that have the same or belong to the same preset semantic category semantic tags; If the comparison results show that the definition of the element differs in different business models, then a semantic conflict is determined to exist; If the comparison results show that the data type or field structure of the element differs in different business models, then a data conflict is determined to exist. If the comparison results show that the operational logic or constraints of the element are contradictory in different business models, then a behavioral conflict is determined to exist.

3. The method according to claim 1, characterized in that, The automatic resolution of the identified conflicts based on a predefined conflict resolution rule base includes: For conflicts of the defined rule type in the conflict resolution rule base, the corresponding resolution rule is invoked for automatic resolution. For conflicts in the conflict resolution rule base where no rule type is defined, a prompt word containing the conflict type and conflict content is constructed, the prompt word is sent to the large language model, the resolution strategy returned by the large language model is received, and the resolution strategy is converted into a resolution scheme. The resolution solution is output for user confirmation, and the resolution solution confirmed by the user can be used to update the conflict resolution rule base.

4. The method according to claim 1, characterized in that, The construction of the fusion graph based on the resolved business models includes: A directed graph is constructed using the entities in each of the aforementioned business models as nodes and the relationships between entities as edges. The edges in the directed graph are configured to carry data flow information and / or call timing information corresponding to the associated relationships.

5. The method according to claim 1, characterized in that, The generation of layered code for the backend service based on the fusion graph includes: Entity layer code is generated based on the entity nodes in the fusion graph; Data access layer code is generated based on the relationships between entities in the fusion graph; Based on the relationships and call sequence in the fusion graph, business logic layer code is generated, which includes transaction management code, exception handling code and / or compensation mechanism code. The interface layer code is generated based on the business logic layer code. The interface layer code includes an application programming interface and / or an interface description document that conforms to the expressive state transfer specification.

6. The method according to claim 1, characterized in that, The method further includes performing the following steps when any of the business models changes: Determine the details of the changes; Based on the changes, the affected entity nodes are determined in the fusion graph, and the change impact domain is obtained by traversing the adjacency relationship and propagation path in the fusion graph starting from the entity node. The change impact domain includes the entities, associations and / or code files affected by the changes. Only the code within the affected domain of the change is incrementally regenerated.

7. The method according to claim 1, characterized in that, Also includes: Cluster analysis is performed based on the fusion graph to identify the coupling degree between entities; Based on the coupling degree, the entity is divided into at least two candidate microservices, and service boundary definitions and inter-service communication contracts are generated for each candidate microservice. Based on the partitioning results of the candidate microservices, a containerized deployment description file is generated.

8. A backend service construction system based on the fusion of multiple business models, comprising: The model acquisition module is used to acquire at least two business models, wherein the business models include entity definitions, attribute definitions, operation definitions and constraint definitions; The model conversion module is used to convert each of the business models into an intermediate representation with unified semantic tags, which are used to identify the semantic type and attributes of each element; The conflict detection module is used to perform difference detection on the intermediate representation and identify semantic conflicts, data conflicts and / or behavioral conflicts between the various business models. The conflict resolution module is used to automatically resolve the identified conflicts based on a predefined conflict resolution rule base. The graph construction module is used to construct a fusion graph based on the resolved business models. The fusion graph is used to characterize the relationships, data flow and / or call sequence between entities contained in each business model. The code generation module is used to generate layered code for the backend service based on the fusion graph and according to a preset layering strategy. The layered code includes entity layer code, data access layer code, business logic layer code, and interface layer code.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images