Low-code management system for microservice-oriented domain objects

Abstract

The application discloses a low-code management system for micro-service-oriented domain objects, comprising: a business design module, which outputs a domain modeling scheme supporting domain-driven design in the form of an interactive design tool after obtaining business requirements; a compiling module, which obtains the domain modeling scheme and generates a corresponding micro-service code framework for each bounded context using a specified technology stack; and a running module, which constructs a domain model operation proxy object to realize micro-service to complete specific business logic. The scheme of the application centrally manages the processes and data exchange related to domain object management, forms a modular scheme, standardizes the processes, greatly reduces the maintenance cost of business objects for application iteration, and enables the research and development work to focus on the design and implementation of core domain logic.

Description

Technical Field

[0001] This application relates to the field of application automatic development technology, and more particularly to a low-code management system for domain objects oriented towards microservices. Background Technology

[0002] Because microservice architecture can decompose and model complex business logic into a series of strongly cohesive, loosely coupled microservices, it can effectively control the complexity of business design and implementation, and has become the mainstream solution for implementing current internet business applications. However, with repeated iterations and functional expansions, it also brings about increasingly serious problems, making it difficult to efficiently advance business maintenance and development:

[0003] 1. In business development, numerous domain models are defined to describe business objects. Due to the decentralized governance of business chains in microservices, it is extremely easy to generate a large number of model versions with inconsistent attributes and constraints for the same business object. These versions will proliferate in the upstream and downstream of the call chain and in different business modules, bringing huge costs to business maintenance and expansion. Figure 1 ).

[0004] 2. In microservices, the business models defined by service providers often fail to quickly meet business needs when new features are added. These models may lack necessary attributes that require additional assembly, or they may be excessively complex, containing many attributes that callers do not need. If not effectively controlled, developers will frequently modify the called services, expanding numerous model definitions and service entry points, making continuous business maintenance difficult.

[0005] 3. A significant portion of R&D work is devoted to handling non-business logic. Due to the maintenance of numerous business models in service implementations, coupled with best practices in microservice development's layered architecture (interface layer, service layer, persistence layer), developers need to write a large amount of code for:

[0006] 1) The bidirectional transformation of the domain model (DO), presentation model (VO), and persistence model (PO) of business objects, as well as the transformation process of query parameter objects between layers.

[0007] 2) Mapping of service entry points between the interface layer and the service layer

[0008] 3) Mapping between service layer business object persistence logic and persistence layer database access.

[0009] 4) Mapping of external domain object access and remote RPC service invocation and assembly in the service layer.

[0010] The code and business logic in this part of the work are mixed together, making it impossible for developers to focus on the core business value.

[0011] 4. The complete domain model becomes increasingly fragmented after multiple iterations, leaving product and technical teams with only a haphazard understanding of the entire business domain. In the current software version iteration process, the product team outputs a domain model diagram of business objects in the Product Development Document (PRD). Developers then build an ER (Entity Retention) persistence model based on the model definitions in the PRD to implement the persistence solution for business objects. After multiple version iterations, the product's domain model becomes a series of "sub-domain diagrams" scattered across various PRD versions; the business persistence model described by developers' code is also scattered across code snippets in various microservices. It becomes extremely difficult for any party on the team to quickly reconstruct a "complete" business domain model diagram from the existing work. When iterating and optimizing existing business logic is required, assessing the impact becomes a very challenging task. Summary of the Invention

[0012] To address the aforementioned technical issues, embodiments of this application provide a low-code management system for domain objects oriented towards microservices, forming a complete toolchain solution to achieve an automated code writing scheme for microservices.

[0013] This application provides a low-code management system for microservice-oriented domain objects, which may include:

[0014] The business design module, after acquiring business requirements in the form of an interactive design tool, outputs a domain modeling scheme that supports domain-driven design. The domain modeling scheme includes a domain boundary and collaboration relationship unit, a domain object unit, and a state information management unit. The domain boundary and collaboration relationship unit includes the definition of bounded contexts and the collaborative working relationships between bounded contexts in the domain modeling design.

[0015] The compilation module obtains the domain modeling scheme, generates the corresponding microservice code framework for each bounded context using the specified technology stack, generates a unified interface for interaction between microservices based on the collaborative working relationship between bounded contexts, and encapsulates the domain object unit and state information management unit into a standard process internally.

[0016] The runtime module constructs domain model operation proxy objects. Microservices request access to or operation on business objects from the domain model operation proxy objects according to business needs. The domain model operation proxy objects work together with proxy objects in other services in the microservice cluster according to the standard process generated by the domain model in the compilation module to form a service mesh of domain objects, complete the local or remote loading, assembly and delivery of domain objects, so as to enable microservices to complete specific business logic.

[0017] Furthermore, the domain object unit includes entities, value objects, aggregates, associations, and domain association graphs within the bounded context.

[0018] Furthermore, the domain object unit describes the type, description, and constraint information of each attribute for entities, value objects, and aggregates.

[0019] Furthermore, the domain association graph in the domain object unit defines the association relationship between each domain entity, including the association type and whether each end of the association relationship can be empty; the association type includes one-to-one, one-to-many, many-to-one, and many-to-many.

[0020] Furthermore, the status information management unit includes resource library configuration and domain event definition.

[0021] Furthermore, the resource repository configuration includes external data source address configuration, as well as the mapping relationship and bidirectional conversion strategy between various entities and data tables in the data source.

[0022] Furthermore, the bidirectional conversion strategy includes a persistence strategy and a deserialization strategy to enable CRUD operations on data tables in the database. The persistence strategy represents saving to the database, while the deserialization strategy represents loading from the database.

[0023] Furthermore, the definition of the domain event is used to describe the publish and subscribe relationship configuration for changes in the state of domain entities.

[0024] Furthermore, the compilation module generates domain object class definitions and association graphs for the domain layer based on the service layering logic driven by the domain model. It then radiates outward from the domain layer to generate the persistence scheme for the base layer, the event sending and receiving mechanism for the application layer, the RPC call assembly mechanism, and the implementation of external and RPC interfaces for the interface layer.

[0025] Furthermore, the compilation module encapsulates the lifecycle management, persistence and loading, query retrieval, RPC access and delivery, and domain event delivery and subscription of domain objects.

[0026] The proposed solution centrally manages all processes and data exchange related to domain object management, forming a modular solution with standardized processes. This significantly reduces the maintenance costs of business objects during application iterations, allowing R&D efforts to focus on the design and implementation of core domain logic. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1This is a system flowchart provided in the embodiments of this application;

[0029] Figure 2 It is a domain object service mesh based on domain proxy collaboration at runtime;

[0030] Figure 3 This is a schematic diagram illustrating the configuration effect of bounded context and domain object definition in the business design module of the embodiment;

[0031] Figure 4 This is a schematic diagram of the resource library configuration in the domain modeling of the embodiment;

[0032] Figure 5 This is a schematic diagram of domain events defined in the domain modeling of the embodiment;

[0033] Figure 6 This is a flowchart of the domain model construction process;

[0034] Figure 7 This is a diagram illustrating the working principle of a domain proxy within a microservice example.

[0035] Figure 8 This is an example diagram of a domain query;

[0036] Figure 9 This is a flowchart of the bottom-up positioning sequence for domain queries;

[0037] Figure 10 This is a top-down assembly sequence flowchart for domain query. Detailed Implementation

[0038] To make the purpose, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] In the description of this application, it should be understood that the terms "upper", "lower", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used 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, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0040] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. This embodiment uses the solution of this application to implement an example microservice application for to-do item allocation and management. In the application, users can create, modify, and delete a series of to-do items, categorizing them into corresponding to-do item groups based on their themes. Furthermore, to-do items can be assigned to specific users, and the completion status of to-do items can be tracked and changed.

[0041] The entire low-code management system for microservice-oriented domain objects includes business design modules, compilation modules, and runtime modules.

[0042] The business design module, presented as an interactive design tool, helps business designers quickly generate modeling solutions that support domain-driven design based on business needs.

[0043] The following units are presented as elements in the formation of the modeling scheme:

[0044] Domain boundary and collaboration relationship units, based on DDD cohesion and collaboration relationships, delineate bounded contexts within the domain and the mapping relationships between them. In this embodiment, according to application requirements, two contexts are divided: task and user, where the user context is upstream of the task context.

[0045] Domain object units include entities, value objects, aggregates, relationships, and domain relationship graphs.

[0046] In this unit, aggregates are defined in each bounded context, and aggregate roots, entities, value objects, and relationships between domain entities are defined within them. In the embodiment, two aggregates, "Task" and "Task List," are defined under the task bounded context, each including a unique entity: "Task Entry" and "Task List," which serve as the roots of their respective aggregates; under the user bounded context, a user aggregate is defined, with the user entity as the aggregate root.

[0047] Forming domain object definition units: This requires describing the type, description, constraints, and other information of each attribute for entities and value objects; taking the attribute "task description" of the task entry entity in the embodiment as an example... Figure 3 The document provides the type, description, and constraints of this attribute. Its type is "Text," and the constraints are "maximum 256 characters" and "can be empty."

[0048] To form a domain relationship graph unit, it is necessary to define the relationship between each domain entity, including one-to-one, one-to-many, many-to-one, many-to-many, etc., and describe whether each end of the relationship can be empty.

[0049] In this embodiment, within the task context, there is a many-to-one relationship between the entities "task entry" and "task list," where the task entry side can be empty, meaning a task list can contain no entries. Similarly, there is a many-to-one relationship between the entity "task entry" in the task context and the entity "user" in the user context, but both ends can be empty; that is, there can be task entries that are not assigned to any user, or there can be a user who has not been assigned any task entries. Figure 4 ).

[0050] The status information management unit includes a resource repository and domain events.

[0051] The resource repository configuration includes:

[0052] The external data source (database) address configuration specifies all databases used by the application for storing domain object data. In this example, two data sources are configured: MySQL data source 1 and MongoDB data source 2, specifying their database addresses, usernames, passwords, and other information to store different domain entities.

[0053] The mapping relationships and bidirectional conversion strategies between various entities and data tables in the data source are described. In the embodiment, the design scheme specifies that the entities "task item" and "task list" are mapped to the data tables task_item and task_list in data source 1, and "user" is mapped to the data table user in data source 2. The bidirectional conversion strategy is configured, mainly describing the conversion formulas between the attributes in the entities and the columns in the data tables.

[0054] The storage configuration of the data tables in the data source for the relationships between various entities. A relationship involves two entities, and to ensure storage and access efficiency, the relationship maps to a data table attribute corresponding to a domain entity. For example, in a many-to-one relationship, an attribute is selected from the data table of the "many" entity to store the ID of the other "one" entity, implementing the 3NF normal form of the data design. In this embodiment, the relationships "Task Item-User Association" and "Task Item-List Association" are both stored in the data table corresponding to the entity "Task Item," corresponding to the attributes "Responsible Person" and "Belonging List," respectively.

[0055] Domain event configuration describes the mapping from domain entity state changes to domain events.

[0056] In this embodiment, changes to the task status attribute of the entity "task entry" may be used to modify the "number of unfinished tasks" statistics for a user. This can be achieved by publishing and subscribing to domain events that trigger the status change. Figure 5The document describes the basic information of the event definition, including the associated entities of the event, the publishing conditions, the event parameters, and the subscription group of the event. The group includes all the aggregates that subscribe to the event and the entry point for consuming the event.

[0057] The contents of the above unit modules can be seen in the table below.

[0058]

[0059] After the entire business design module constructs the modeling scheme in the above manner, the compilation module obtains the domain modeling scheme, generates the domain object management code logic for the microservice technology stack, and encapsulates the standard process implementations such as domain object lifecycle management, persistence and loading, query retrieval, RPC access and delivery, domain event delivery and subscription.

[0060] Specifically, based on the domain model-driven service layering logic, the domain object class definitions and association graphs for the domain layer are first generated. Then, radiating outwards from this core, the persistence scheme for the base layer, the event sending and receiving and RPC call assembly mechanism for the application layer, and the external and RPC interface implementations for the interface layer are generated. Ultimately, developers only need to focus on implementing the application services for the application layer and the domain services for the domain layer. See below for the detailed code generation process. Figure 6 .

[0061] The runtime module constructs a domain model operation proxy model. Microservices request access to or manipulation of business objects from this proxy model based on business needs. The proxy objects, following the standard process generated by the domain model in the compilation module, collaborate with proxy objects in other services within the microservice cluster to form a service mesh of domain objects. This mesh handles the loading, assembly, and delivery of domain objects, enabling microservices to complete specific business logic. The microservice cluster contains multiple independent microservice instances, each responsible for different business functions. A bounded context generates a microservice, and these microservices communicate and collaborate to form a cluster that completes a full business function.

[0062] As a specific implementation example, the service example has integrated a domain model object runtime engine (domain object access proxy). This engine proxies all access and retrieval of domain model resources. Together with the domain model definition generated by the code generator and other auxiliary logic, it hides all implementation details of the domain layer, allowing business logic to directly manipulate domain objects.

[0063] Business logic can initiate query requests to the domain object access proxy within its own microservice instance when necessary, according to its own needs. The proxy will query and assemble the domain object query results based on the domain model and return them to the business logic.

[0064] 1) The domain entity query object needs to describe the following content of the query:

[0065] - Root Entity: This is the entity in the subject domain to be queried. It specifies the domain path, in the form of: <bounded context>:<aggregate name> / <entity name>. For example, the domain path for "task item" in the example is: todo:todoItem / todoItem

[0066] - Query Group: Each query object describes the query content of the root entity or the entity associated with its domain.

[0067] - Assembly Attributes: Descriptions of the assembly requirements for query results, including entity attributes that need to appear in the result set for the root entity or other entities related to the root entity in the domain association graph.

[0068] - Other information: Other information about the query, such as sorting, result set size, etc.

[0069] For example, Figure 6 The example provides a query request for the sample application. The root entity of the query is "task item," and the query condition is: high-priority task items that Zhang San is responsible for must be completed before July 20, 2022. The query results should include all the attributes of the "task item" and the name of its corresponding "task list."

[0070] 2) Within the entire domain association graph, analyze the root entity and its associated entities appearing in the query, constructing the subgraphs of these entities into two tree structures rooted at the root entity. The entire query process can then be modeled as two steps:

[0071] - Locate the root entity object by bottom-up lookup: See details below. Figure 9

[0072] - Assemble query result attributes from top to bottom: See details for steps. Figure 10 .

[0073] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details of the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations (such as quantity, shape, position, etc.) can be made to the technical solutions of the present invention, and these equivalent transformations are all protected by the present invention.

Claims

1. A low-code management system for domain objects oriented towards microservices, characterized in that, include: The business design module uses an interactive design tool to obtain business requirements and then outputs a domain modeling solution that supports domain-driven design. The domain modeling scheme includes a domain boundary and collaborative relationship unit, a domain object unit, and a state information management unit; The domain boundary and collaborative relationship unit includes the definition of bounded contexts in domain modeling design and the collaborative working relationships between bounded contexts; The compilation module acquires the domain modeling scheme, generates corresponding microservice code frameworks for each bounded context using the specified technology stack, generates a unified interface for interaction between microservices based on the collaborative working relationship between bounded contexts, and encapsulates domain object units and state information management units into standard processes internally. Based on the service layering logic driven by the domain model, the compilation module generates domain object class definitions and association graphs for the domain layer, and radiates outwards from the domain layer to generate the persistence scheme for the base layer, the event sending and receiving mechanism for the application layer, the RPC call assembly mechanism, and the implementation of external and RPC interfaces for the interface layer. The runtime module constructs domain model operation proxy objects. Microservices request access to or operation on business objects from the domain model operation proxy objects according to business needs. The domain model operation proxy objects work together with proxy objects in other services in the microservice cluster according to the standard process generated by the domain model in the compilation module to form a service mesh of domain objects, complete the local or remote loading, assembly and delivery of domain objects, so as to enable microservices to complete specific business logic.

2. The low-code management system for microservice-oriented domain objects according to claim 1, characterized in that, The domain object unit includes entities, value objects, aggregates, associations, and domain association graphs within the bounded context.

3. The low-code management system for microservice-oriented domain objects according to claim 2, characterized in that, The domain object unit describes the type, description, and constraint information of each attribute for entities, value objects, and aggregates.

4. The low-code management system for microservice-oriented domain objects according to claim 2, characterized in that, The domain association graph in the domain object unit defines the association relationship between each domain entity, including the association type and whether each end of the association relationship can be empty; the association type includes one-to-one, one-to-many, many-to-one, and many-to-many.

5. The low-code management system for microservice-oriented domain objects according to claim 1, characterized in that, The status information management unit includes resource library configuration and domain event definition.

6. The low-code management system for microservice-oriented domain objects according to claim 5, characterized in that, The resource repository configuration includes the configuration of external data source addresses, as well as the mapping relationship and two-way conversion strategy between various entities and data tables in the data source.

7. The low-code management system for microservice-oriented domain objects according to claim 6, characterized in that, The bidirectional conversion strategy includes a persistence strategy and a deserialization strategy to enable CRUD operations on data tables in the database.

8. The low-code management system for microservice-oriented domain objects according to claim 5, characterized in that, The definition of the domain event is used to describe the configuration of the publish and subscribe relationships for changes in the state of domain entities.

9. The low-code management system for microservice-oriented domain objects according to claim 1, characterized in that, The compilation module encapsulates the lifecycle management, persistence and loading, query retrieval, RPC access and delivery, and domain event delivery and subscription of domain objects.

Images