Model orchestration method and system
Define business models through the model orchestration engine, generate metadata and automatically generate storage structures, provide data access interfaces and page interactive orchestration components, solve the complexity and scalability problems of traditional model orchestration, and realize flexible and efficient model orchestration and security management.
Patent Information
- Application Number
- CN202510166496.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-14
- Publication Date
- 2025-07-04
AI Technical Summary
Traditional model orchestration has problems such as complexity and maintenance difficulties, limited scalability and flexibility, resulting in high development and maintenance costs and difficulty in adapting to rapidly changing needs and technical environments.
The model orchestration engine is used to define the business model, generate metadata, automatically generate storage structures through the metadata management module, and use the data access module to provide a data access interface. The page interactive orchestration module automatically generates orchestration components, realizing the isolation of logical definitions and physical definitions, and supporting visualization and code-level orchestration methods.
It improves the flexibility and efficiency of model orchestration, reduces maintenance costs, supports dynamic adjustment and security management, adapts to different task requirements, and improves the adaptability and reusability of the system.
Smart Images

Figure CN120255877A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of model orchestration, and particularly to a method and system for model orchestration. Background Art
[0002] Traditional model orchestration has some inherent drawbacks that may affect the efficiency, flexibility, and scalability of model orchestration.
[0003] Complexity and maintenance difficulties: As the number of models increases and the orchestration logic becomes more complex, the complexity of the entire system will increase significantly. This may make it difficult for the development team to understand and maintain the entire orchestration process, especially for new developers joining the team. When a model needs to be updated or modified, the entire process may need to be re-orchestrated to ensure the correctness and stability of the system. This increases the maintenance cost and time cost.
[0004] Limited scalability and flexibility: Traditional model orchestration may be difficult to adapt to rapidly changing requirements and technological environments. When new models or functions need to be added, the entire orchestration process may need to be redesigned, which increases the difficulty and cost of system expansion. Due to the fixed nature of the orchestration logic and the dependencies between models, traditional model orchestration may be difficult to adjust flexibly to meet different task requirements, limiting the adaptability and reusability of the system. Summary of the Invention
[0005] In view of this, the purpose of this application is to propose a method and system for model orchestration.
[0006] Based on the above purpose, this application provides a model orchestration method applied to a model orchestration system, where the model orchestration system includes: a model orchestration engine, a metadata management module, a data access module, and a page interaction orchestration module;
[0007] The method includes:
[0008] In response to the model orchestration requirement, use the model orchestration engine to define the business model and obtain metadata;
[0009] Use the metadata management module to receive the metadata and automatically generate a storage structure;
[0010] Based on the metadata, use the data access module to provide a data access interface for the page interaction orchestration module;
[0011] Use the page interaction orchestration module to automatically generate orchestration components based on the data information stored in the data access module to complete model orchestration.
[0012] In a possible implementation, using the model orchestration engine to define a business model to obtain metadata, including:
[0013] Using the model orchestration engine to define entities and entity relationships in the business model to obtain the metadata.
[0014] In a possible implementation, based on the metadata, using the data access module to provide a data access interface for the page interaction orchestration module, including:
[0015] Based on the metadata, using the data access module for the data logic of dynamic query and data operation;
[0016] Based on the data logic, providing a data access interface for the page interaction orchestration module.
[0017] In a possible implementation, based on the data logic, providing a data access interface for the page interaction orchestration module, including:
[0018] Based on the data logic, providing a data access interface for the page interaction orchestration module through the GraphQL protocol.
[0019] In a possible implementation, the method further includes:
[0020] In response to a data change event, using the metadata management module to synchronize the first change data corresponding to the data change event to the data access module.
[0021] In a possible implementation, the method further includes:
[0022] In response to data changes in the data access module, the page interaction orchestration module automatically changes the component orchestration based on the data changes to complete the update of the model orchestration.
[0023] In a possible implementation, the method further includes: judging the security of the change event;
[0024] In response to the change event being insecure, generating a data definition language audit form based on the change event;
[0025] In response to the audit form passing the audit, continuing to process the change event.
[0026] In a possible implementation, the method further includes:
[0027] Based on the data permissions in the model orchestration requirements, using the metadata management module to limit the access permissions to the metadata.
[0028] In a possible implementation, the method further includes:
[0029] In response to a direct change event of the orchestration component, the page interaction orchestration module is used to synchronize second change data corresponding to the direct change event of the orchestration component to the data access module.
[0030] Based on the same inventive concept, an embodiment of the present application further provides a model orchestration system, including: a model orchestration engine, a metadata management module, a data access module, and a page interaction orchestration module;
[0031] The model orchestration engine is configured to define a business model in response to the model orchestration requirement to obtain metadata;
[0032] The metadata management module is configured to receive the metadata and automatically generate a storage structure;
[0033] The data access module is configured to provide a data access interface for the page interaction orchestration module based on the metadata;
[0034] The page interaction orchestration module is configured to automatically generate an orchestration component based on the data information stored in the data access module to complete model orchestration.
[0035] As can be seen from the above, for the model orchestration method and system provided by the present application, in response to the model orchestration requirement, the model orchestration engine is used to define a business model to obtain metadata; the metadata management module is used to receive the metadata and automatically generate a storage structure; based on the metadata, the data access module is used to provide a data access interface for the page interaction orchestration module; the page interaction orchestration module is used to automatically generate an orchestration component based on the data information stored in the data access module to complete model orchestration. Model orchestration no longer directly defines database tables, but defines logical models with business meanings and relationships between models. Subsequent adjustments to the models will synchronize these changes at the system global level, affecting the storage layer, data services, and page interactions. This model orchestration ability realizes the isolation between logical definition and physical definition. This orchestration ability provides a model orchestration method for a visual console and also provides a model orchestration method at the code level for the convenience of developers. The visual method is relatively flexible and can take effect immediately without code deployment operations, but for more complex logical processing, it can be orchestrated and assembled through the code implementation method. The two methods can be used in combination as needed to provide a more powerful orchestration ability. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] To more clearly illustrate the technical solutions in the present application or related technologies, the following will briefly introduce the drawings required for use in the embodiments or related technology descriptions. Obviously, the drawings in the following descriptions are only embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.
[0037] Figure 1 Schematic flowchart of the method for model orchestration according to an embodiment of the present application;
[0038] Figure 2 ER schematic diagram of the business service layer according to an embodiment of the present application;
[0039] Figure 3 Schematic structural diagram of the system for model orchestration according to an embodiment of the present application. Detailed implementation manners
[0040] To make the objectives, technical solutions, and advantages of the present application clearer and more understandable, the following further details the present application in conjunction with specific embodiments and with reference to the accompanying drawings.
[0041] It should be noted that unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should have the ordinary meaning understood by those with ordinary skills in the field to which the present application belongs. The "first", "second", and similar terms used in the embodiments of the present application do not indicate any order, quantity, or importance, but are only used to distinguish different components. "Including" or "comprising" and similar terms mean that the elements or objects appearing before this term cover the elements or objects listed after this term and their equivalents, without excluding other elements or objects. "Connection" or "coupling" and similar terms are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Upper", "lower", "left", "right", etc. are only used to represent relative positional relationships, and when the absolute position of the object being described changes, the relative positional relationship may also change accordingly.
[0042] It can be understood that before using the technical solutions of the various embodiments of the present disclosure, the types, usage scopes, usage scenarios, etc. of the personal information involved will be informed to the user in an appropriate manner, and the user's authorization will be obtained.
[0043] For example, when receiving the user's active request, a prompt message is sent to the user to clearly prompt the user that the operation requested by the user will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application program, server, or storage medium that performs the operations of the technical solutions of the present disclosure according to the prompt message.
[0044] As an optional but non-limiting implementation, in response to receiving an active request from a user, the manner of sending a prompt message to the user may be, for example, in the form of a pop-up window, and the prompt message may be presented in text in the pop-up window. In addition, the pop-up window may also carry selection controls for the user to select "agree" or "disagree" to provide personal information to the electronic device.
[0045] It can be understood that the above notification and user authorization acquisition process is only illustrative and does not constitute a limitation on the implementation manner of the present disclosure. Other manners that comply with relevant laws and regulations can also be applied to the implementation manner of the present disclosure.
[0046] As described in the background art section, traditional model orchestration has some inherent drawbacks, which may affect the efficiency, flexibility, and scalability of model orchestration.
[0047] Complexity and maintenance difficulties: As the number of models increases and the orchestration logic becomes more complex, the complexity of the entire system will increase significantly. This may make it difficult for the development team to understand and maintain the entire orchestration process, especially for developers newly joining the team. When a model needs to be updated or modified, the entire process may need to be re-orchestrated to ensure the correctness and stability of the system. This increases the maintenance cost and time cost.
[0048] Limited scalability and flexibility: Traditional model orchestration may be difficult to adapt to rapidly changing requirements and technological environments. When new models or functions need to be added, the entire orchestration process may need to be redesigned, which increases the difficulty and cost of system expansion. Due to the fixed nature of the orchestration logic and the dependencies between models, traditional model orchestration may be difficult to flexibly adjust to meet different task requirements, limiting the adaptability and reusability of the system.
[0049] Taking the above considerations into account, an embodiment of the present application proposes a method for model orchestration. In response to the model orchestration requirement, the model orchestration engine is used to define a business model to obtain metadata; the metadata management module is used to receive the metadata and automatically generate a storage structure; based on the metadata, the data access module is used to provide a data access interface for the page interaction orchestration module; the page interaction orchestration module is used to automatically generate orchestration components based on the data information stored in the data access module to complete model orchestration. Model orchestration no longer directly defines database tables, but defines logical models with business meanings and relationships between models. Subsequent adjustments to the models will synchronize these changes at the system global level, affecting the storage layer, data services, and page interactions. This model orchestration ability realizes the isolation between logical definition and physical definition. This orchestration ability provides a model orchestration method with a visual console and also provides a model orchestration method at the code level for the convenience of developers. The visual method is relatively flexible and can take effect immediately without code deployment operations, but more complex logical processing can be orchestrated and assembled through the code implementation method. The two methods can be used in combination as needed to provide a more powerful orchestration ability.
[0050] The following will detail the technical solutions of the embodiments of the present application through specific embodiments.
[0051] Reference Figure 1 , the method for model orchestration of the embodiments of the present application includes the following steps:
[0052] Step S101, in response to the model orchestration requirement, use the model orchestration engine to define a business model to obtain metadata;
[0053] Step S102, use the metadata management module to receive the metadata and automatically generate a storage structure;
[0054] Step S103, based on the metadata, use the data access module to provide a data access interface for the page interaction orchestration module;
[0055] Step S104, use the page interaction orchestration module to automatically generate orchestration components based on the data information stored in the data access module to complete model orchestration.
[0056] Regarding step S101, before implementing model orchestration, basic requirement analysis and system preparation work need to be completed.
[0057] First, it is necessary to determine business requirements and model boundaries.
[0058] Requirement collection: Communicate with the business department and product team to clarify business requirements, especially the key areas, sub-domains, and general domains that need to be supported.
[0059] Business scope analysis: Based on business needs, sort out business processes and determine the business domain objects (DO) that need to be covered.
[0060] Domain boundary division: Identify aggregate roots, entities, and value objects in the domain model, and clarify domain boundaries and contextual relationships.
[0061] Then proceed to domain driven modeling.
[0062] The core of domain-driven design is to establish a clear model and define the model semantically:
[0063] Subdomain division: Divide business requirements into subdomains (core domain, supporting domain, and general domain) according to different business objectives.
[0064] Domain model design: Identify and define domain objects, including entities, aggregates, value objects, and aggregate roots.
[0065] Model relationship representation: The relationships of the model are represented through ER diagrams or domain context diagrams, including associations and references between aggregations.
[0066] Next, you need to determine the technology selection. Specifically, you need to choose the appropriate technology stack to support the model orchestration function:
[0067] Data access layer: supports structured storage (such as relational databases) and unstructured storage (such as document databases);
[0068] Data service interface: uses the GraphQL protocol to provide unified data access capabilities;
[0069] Orchestration tools: determine the visualization tool framework to be used to support online model definition;
[0070] Code Generation: Select a code generator to dynamically generate domain service code.
[0071] After the definition is completed, for step S101, in response to the model orchestration requirement, the model orchestration engine is used to complete the definition of the business model and generate metadata.
[0072] In some embodiments, using the model orchestration engine to define the business model and obtain metadata includes: using the model orchestration engine to define entities and entity relationships in the business model to obtain the metadata.
[0073] The object of model orchestration is the business model (DO), and the entity-relationship model (ER) modeling method is adopted. Metadata-driven automatic mapping of database tables realizes unified access to data. Domain architects can quickly construct a panoramic view of the domain composed of domain object models such as domains, sub-domains, common domains, support domains, entities, value objects, aggregates, and aggregate roots. Domain architects only focus on domain design, and through the definition of models, dynamically generate the code framework of domain services, construct a data service code framework that shields database differences, and generate a unified and efficient interface interaction upward based on the models, and generate a persistent data storage structure downward, reducing the amount of code. Tooling and onlineization improve the collaboration efficiency between the design team and the R & D team, ensure the consistency and controllability of architecture design and R & D implementation, and improve the quality of code delivery.
[0074] Reference Figure 2 , which is the ER schematic diagram of the business service layer of the embodiment of the present application.
[0075] As Figure 2 shown, the business microservice layer will contain multiple business microservices, and these business microservices can be combined into multiple domains (centers).
[0076] A domain is a logical concept, and a domain can contain multiple sub-domains, that is, multiple business microservices; a sub-domain is a physical concept and will be materialized into a Spring Boot application. Spring Boot is a lightweight Java application development framework.
[0077] The concepts of domain and sub-domain need to be reflected in the service center list display of the New Business Framework (NBF). The concepts of domain, sub-domain, aggregate, aggregate root, entity, value object, attribute, and method need to be reflected in the model center list display of Trantor. Note that aggregates, aggregate roots, entities, value objects, attributes, and methods do not need to be reflected in the NBF. In addition, currently Trantor only has the concept of sub-domain and no concept of domain, which needs to be added. Trantor is a model design and management platform and a tool for displaying domains, sub-domains, and their related models.
[0078] There is only one aggregate root under an aggregate, and there can be multiple entities. The aggregate root is a special entity. If an entity belongs to an aggregate, it can only belong to one aggregate and cannot belong to multiple aggregates across different aggregates, that is, it cannot belong to both aggregate A and aggregate B.
[0079] An aggregate root is a special entity. Operations on entities within the same aggregate must be indexed and routed through the aggregate root uniformly. In most cases, an entity necessarily belongs to a certain aggregate. However, there are also some cases where an entity cannot be grouped into a particular aggregate. In such cases, operations on the entity degenerate into traditional direct operations that are not domain-driven design (DDD).
[0080] The DO entity model defined in the business microservice layer is a persistence model. Trantor needs to distinguish it from the view object (VO) non-persistence model defined in the front-end microservice layer during display.
[0081] Users can define business entities and their relationships through an online visual configuration interface or by means of code annotations. Model orchestration requirements may include creating new models, adding model fields, modifying model relationships, etc.
[0082] First, users define business models through the model orchestration engine. The defined content includes entity names, field names, field types, field constraint conditions (such as primary key, non-null, etc.), default values, and the business meanings of the fields. In addition, users can define relationships between entities, such as one-to-one, one-to-many, many-to-many, etc. association relationships. The definition of the model can be based on concepts in DDD, such as aggregates, aggregate roots, entities, and value objects, or simply meet traditional data modeling requirements.
[0083] The model orchestration engine will generate corresponding metadata according to the user's input. This metadata is an abstract model data that contains structural information of entities, business rules, relationship information, and permission rules, etc., serving as the execution basis for subsequent modules.
[0084] In a feasible embodiment, in an e-commerce system, a user defines an "order" model through the model orchestration engine. The fields of this model include order number, total order amount, and creation time. Among them, the "order number" is defined as the primary key, the "total order amount" is defined as a non-negative number, and the "creation time" is given a default value of the current time. At the same time, the user also defines a "many-to-one" relationship between "order" and "user", and a "one-to-many" relationship between "order" and "order item". After the definition is completed, this information is converted into metadata for driving subsequent modules.
[0085] Regarding step S102, the automatic generation of the storage structure.
[0086] In this embodiment, the metadata management module receives the metadata generated by the model orchestration engine, parses the model structure and relationship information, and automatically generates a storage structure. The core of this step is to decouple the logical model from the physical storage model, and dynamically generate a database table structure or a distributed storage structure through metadata-driven, avoiding developers from manually writing data definition languages.
[0087] The metadata management module analyzes the field information of the model and generates a suitable storage structure according to the model definition. For a relational database, it generates the definitions of database tables and fields, and generates primary keys, foreign keys, indexes, etc. according to the model relationships. For distributed storage (such as key-value storage or document storage), it generates a storage structure corresponding to the model and data serialization rules. In addition, if the model changes (such as adding fields, deleting fields, or adjusting relationships), the metadata management module will synchronously adjust the storage structure and drive data migration.
[0088] In this embodiment, in the above e-commerce system, the metadata management module generates a database table according to the "order" model, which includes three fields: order number, total order amount, and creation time, and adds a foreign key constraint according to the model definition to associate with the user table. At the same time, to support the one-to-many relationship, it also generates the storage structure of order items and establishes the association between orders and order items. In addition, if the user subsequently adds a field "order status" to the model, the metadata management module will dynamically modify the storage structure, add the corresponding field, and automatically complete the structure migration of the existing data.
[0089] For step S103, based on the metadata, the data access module provides a data access interface for the page interaction orchestration module.
[0090] In some embodiments, the step of providing a data access interface for the page interaction orchestration module based on the metadata using the data access module includes: based on the metadata, using the data access module to generate data logic for dynamic query and data operation; based on the data logic, providing a data access interface for the page interaction orchestration module.
[0091] In some embodiments, the step of providing a data access interface for the page interaction orchestration module based on the data logic includes: based on the data logic, providing a data access interface for the page interaction orchestration module through the GraphQL protocol.
[0092] In this embodiment, further, a data access interface is generated.
[0093] Specifically, based on the metadata, the Data Access Module (DataStore) provides a data access interface for the Page Interaction Orchestration Module. The Data Access Module parses the metadata and dynamically generates standardized data logic corresponding to the model definition, including query, insert, update, and delete operations. In addition, the Data Access Module further provides a unified data access interface to shield the differences in underlying storage. It should be noted that the unified data access service of DataStore in this application refers to providing a unified API interface to access the services of different DataStores. It provides a consistent data access method for applications and shields the differences in underlying data storage. This enables developers to not have to worry about the specific implementation of data storage and only need to perform data operations through the unified interface.
[0094] The Data Access Module can also generate the CRUD operation logic (i.e., create, delete, update, query) of the business model by parsing the metadata and support complex association queries based on the model relationships. At the same time, the Data Access Module provides a data interface for the upper-layer module through a standard protocol (such as GraphQL), supporting the return of required fields and association information on demand to improve the query efficiency. In addition, the Data Access Module also dynamically generates field-level and row-level permission control logic according to the permission rules in the metadata to ensure data access security. The above CRUD refers to the acronym of the four words "Create", "Read", "Update", and "Delete", and these four operations constitute the basic framework for managing data in the database and the persistence layer.
[0095] In this embodiment, in an e-commerce system, the Data Access Module generates a data interface for the "order" model, supporting querying order details, inserting new orders, updating order information, and deleting orders. At the same time, the interface supports querying the user information and order item information associated with the order according to user requirements. For example, a page component can call the interface to obtain the total amount of a certain order and the details of the order items without directly operating on the underlying database. In addition, the permission rules restrict that ordinary users can only access their own orders, while administrators can access all orders.
[0096] For step S104, using the Page Interaction Orchestration Module, based on the data information stored in the Data Access Module, an orchestration component is automatically generated to complete model orchestration.
[0097] In this embodiment, using the Page Interaction Orchestration Module, according to the metadata and the data access interface, orchestration components for interface interaction are generated. These components include tables, lists, charts, etc. for data display, and forms, input boxes, etc. for data editing.
[0098] In some embodiments, the method further includes: in response to a data change event, synchronizing first change data corresponding to the data change event to the data access module by using the metadata management module.
[0099] In some embodiments, the method further includes: in response to data changes in the data access module, the page interaction orchestration module automatically changes the component orchestration based on the data changes to complete the update of the model orchestration.
[0100] In some embodiments, the method further includes: judging the security of the change event; in response to the change event being insecure, generating a data definition language review form based on the change event; and in response to the review form passing the review, continuing to process the change event.
[0101] In some embodiments, the method further includes: in response to a direct change event of the orchestration component, synchronizing second change data corresponding to the direct change event of the orchestration component to the data access module by using the page interaction orchestration module.
[0102] In this embodiment, the page interaction orchestration module automatically generates an interface layout and components according to the field information and model relationships in the metadata. For example, appropriate interface elements are generated according to the field type (such as a text box is generated for a string field, a checkbox is generated for a boolean field, etc.). In addition, the page interaction module generates nested components according to the model relationships for displaying data of associated models. After the components are generated, the page interaction orchestration module fills the component data by calling the data access interface to complete the dynamic display and interaction logic of the page. At the same time, if the page interaction module detects a component change event from the user, it will synchronize the change data to the data access module.
[0103] In this embodiment, in an e-commerce system, the page interaction module generates an order management page for the "order" model. The page includes an order list component for displaying the order number, total amount, and creation time; an order details form for viewing and editing information of a single order; and a nested order item table component for displaying the order items associated with the order. If the user modifies the total order amount in the order details form and submits it, the page interaction module will synchronize the change data to the data access module to complete the backend update and automatically refresh the page.
[0104] Furthermore, this application also includes a part for handling change events and security management.
[0105] In the method for handling data change events, when certain data in the system changes (such as modifications to database records, updates to data status caused by background logic operations, or data changes pushed by an external system through an interface), the system will trigger a data change event. The metadata management module is responsible for capturing these data change events and extracting the first change data related to the events. The first change data usually includes the identifier of the modified data item, the changed fields and their new values, and relevant context information (such as data association relationships, structured descriptions, etc.). After capturing these changes, the metadata management module synchronizes them to the data access module. The role of the data access module is to store or update the changed data to ensure that the persistent data within the system (such as database data) is consistent with the latest changes. In addition, the data access module can further notify the associated modules so that other associated systems or front-end components can perceive these changes and update in a timely manner. The advantage of this method is that it can effectively manage the changes in background data, achieve real-time data synchronization, and at the same time, the module responsibilities are clearly separated, making it suitable for handling change scenarios involving background data sources (such as databases or external interface data).
[0106] In the method for handling direct change events of the orchestration component, direct operations by the user at the page interaction layer (such as form input, parameter adjustment, component dragging, status switching, etc.) will trigger direct change events of the orchestration component. The page interaction orchestration module captures these events and generates corresponding second change data. The second change data includes the unique identifier of the component, the specific content of the current change (such as value, status, display attributes, etc.), and the association or dependency relationship between components. The page interaction orchestration module synchronizes this second change data to the data access module. After receiving these data, the data access module stores or updates them to ensure that the operation results of the user can be persistently recorded. If necessary, it can further trigger updates to other modules to ensure the consistency and integrity of the overall page logic. The core feature of this method is its rapid response, which can capture and handle the user's immediate operations, and at the same time, ensure low coupling between components through the orchestration module. In practical applications, this processing method is suitable for scenarios that require real-time feedback on user operations, such as page configuration tools, form interactions, or dynamic page operations, etc.
[0107] In addition, in response to page change events, the metadata management module and the data access module are used to complete the security assessment, data migration, and component update of the changes to ensure the consistency and security of the system.
[0108] When the user modifies the model definition or page components, change events are captured and corresponding change data is generated. The data access module determines the security of the changes, distinguishing between secure and insecure changes. For secure changes (such as adding fields), the system automatically updates the metadata and synchronizes it to the storage structure and data interfaces. For insecure changes (such as deleting fields or modifying field types), the system generates an approval form, which needs to be approved by the administrator before execution. The page interaction module responds to change events in real time and updates the affected page components.
[0109] In this embodiment, in an e-commerce system, the user adds a field "order status" to the "order" model. After the system captures the change event, it directly updates the metadata, adds the corresponding field to the database, and updates the data interface and interface components at the same time, so that the order page automatically adds a status field. Subsequently, the user attempts to delete the field "order number". The system determines that this change is an insecure operation, so it generates an approval form, prompting the user that this field is the primary key and deleting it may cause system exceptions. After approval, the system will execute the deletion operation and synchronize the relevant changes.
[0110] In some embodiments, the method further includes: based on the data permissions in the model orchestration requirements, using the metadata management module to limit the access permissions to the metadata.
[0111] Based on the data permission rules in the model orchestration requirements, use the metadata management module to limit the data permissions, and perform permission verification in the data access module and the page interaction module.
[0112] In this embodiment, the administrator of the e-commerce system can access all orders, while ordinary users can only access their own orders. This rule is recorded in the metadata, and the data access module will automatically filter out orders that do not belong to the current user when querying orders to ensure data security.
[0113] Through the above steps, this technical solution realizes the full-link connection from model definition to storage, data access, and page interaction, supporting dynamic adjustment and security management. This solution significantly improves the flexibility and efficiency of model orchestration, while ensuring business logic consistency and system security.
[0114] In addition, the orchestration of the model in the embodiments of the present application mainly relies on an online visual configuration model, but at the same time also supports the definition in code mode through annotation declarations. The model can be orchestrated into a model relationship that conforms to DDD aggregation through the unique annotations of DDD, or the simple definition of the model can be used to complete the traditional development mode without using DDD annotations.
[0115] In the embodiments of the present application, the model orchestration method mainly relies on an online visual configuration model. This method provides an intuitive and user-friendly interface, facilitating developers to quickly complete the model orchestration work through operations such as dragging, clicking, and setting parameters. The online visual configuration model method can lower the development threshold, enabling developers to complete complex model definitions and orchestrations without in-depth understanding of the underlying technical implementations. At the same time, this method can also dynamically display the relationships and details between models, improving development efficiency and system maintainability.
[0116] In addition to online visual configuration, this embodiment also provides code mode support, where model definitions and orchestrations are carried out by using annotations in the code. In this mode, developers can use the annotations unique to DDD (Domain-Driven Design) to orchestrate the model into a model structure that conforms to the DDD aggregation relationship. For example, developers can use annotations to mark key model elements such as aggregate roots, entities, and value objects, as well as their associations and dependencies. In this way, the model orchestration can not only embody the core idea of domain-driven design but also make the business logic more in line with the actual domain requirements, thereby enhancing the model's expressive ability and maintainability. This annotation-based model definition can highly coincide with the domain layering idea of DDD, enabling developers to clearly construct and maintain the domain model at the code level.
[0117] Furthermore, this embodiment also supports scenarios without using DDD annotations, which means that developers can choose to define the model in a simple way for traditional development modes. In this case, developers do not need to consider the complex concepts of DDD and can directly define the model relationships in a more lightweight manner through annotations or configuration information. This method is applicable to scenarios where development efficiency is prioritized, business requirements are clear, and complex domain modeling is not required, enabling quick realization of model definitions and completion of system development.
[0118] In summary, this embodiment makes the model orchestration more flexible and diverse by supporting both online visual configuration and code mode. Online visual configuration is suitable for developers who hope to get started quickly and operate intuitively, while the code mode implemented through annotations is suitable for developers with in-depth understanding of domain design, especially in scenarios where complex domain models and DDD aggregation relationships need to be constructed. In addition, for simple development scenarios that do not involve domain-driven design, the system provides a simplified model definition method, meeting the requirements of various business scenarios and balancing the relationship between development efficiency and system design complexity.
[0119] In addition, in the embodiments of the present application, management and design functions of the domain model (such as the function view of model orchestration) are also provided for developers, and through this function, the attributes, behaviors, etc. of an object can be completely defined. It includes: sub-domain management, aggregate management, entity management, value object management, domain method management, release management, dictionary management, standard field management, model designer, version management, transport layer management, and attribute management.
[0120] Refer to Table 1 for the schematic diagram of the function view of model orchestration in the embodiments of the present application.
[0121] Table 1 Schematic Diagram of the Function View of Model Orchestration
[0122]
[0123] As shown in Table 1, sub-domain management: provides the function of orchestrating sub-domains under the domain. Sub-domains can be viewed, searched, and edited online. At the same time, sub-domains can be added online to complete the orchestration of sub-domains related to the overall entity in the application development process. Consideration is given to the display of the basic information and included content of the sub-domains, including the list display of various resources such as entities, aggregates, value objects, and services under the sub-domains and related online operation functions.
[0124] Aggregate management: In the entity diagram, information related to the aggregate is carried, and operations can be performed in the entity card to quickly view the relevant aggregate information and quickly display the aggregate in a visual manner.
[0125] Entity management: Filter and view the graphical resources shown in the ER diagram according to the sub-domain information to which the sub-domain or entity belongs, so as to quickly locate and view the entity relationships. In the entity diagram, the one-to-many relationships are shown in a connected line manner, and the relationship fields that cause the association relationships are also shown. The relevant entities will be highlighted. The SDK registration entities include entities and fields, relationships between entities, index information, etc. This Java class is not only used to declare entities, but also to ensure type safety and improve efficiency when writing business code. At the same time, this Java class can also be used to transform the generalized atomic service into an atomic service of a type-safe specific entity. The fields owned by the model are declared through Java member variables. By default, the field types are automatically inferred according to the JavaType of the fields. Add fields to existing entities and overwrite fields. When multiple extended entities exist at the same time, fields with different keys will be merged, and fields with the same key will fail at startup.
[0126] Value object management: mainly includes the management of functions such as value object list, value object identifier, value object name, and entity to which the value object belongs.
[0127] Domain Method Management: Display all entities from a list perspective, support more information display and filtering conditions than the entity resource tree, and can find the target entity more quickly and intuitively. Configure basic information at the non-field level such as entity identification, name, primary key, and ID rules. This information is used for interface display and table structure generation. Configure configuration items related to the unified workbench, such as whether to enable import / export and whether to enable global search. When import / export is enabled, the corresponding entity can be selected in the import / export function of the unified workbench for import / export operations. When global search is turned on, the corresponding entity can be searched at the global search entry above the unified workbench. Entities created based on the console can be deleted in the console, and entities created based on code can be deleted by simply deleting the class definition in the code. Entities are an important unit of entity orchestration, and an entity corresponds to various resources such as fields, views, behaviors, value objects, and services. The entity details are used to display these resources and provide basic modification functions.
[0128] Release Management: Ensure that multiple models can be coordinated, tested, deployed, and monitored in a predetermined order and according to rules.
[0129] Dictionary Management: View and filter data dictionaries in a list manner, and display information such as dictionary name, dictionary key, and dictionary source subdomain, including dictionaries registered from code and dictionaries created in the console. Add or delete data dictionaries. Dictionaries created in the console can be directly deleted, while dictionaries registered based on code need to have the corresponding class deleted in the code. Deletion is not allowed when a dictionary has been referenced by a field. Configure specific dictionary items in a dictionary, including the encoding, value, description, and icon information of the dictionary item, as well as whether to enable or disable existing dictionary items. Enabled dictionary items will be presented as selectable options in interface interactions, usually in the form of a dropdown box. Control whether users in the unified workbench can edit the dictionary. When the business needs to directly open the dictionary editing for business users, developers can enable user-side editing for a specific dictionary here. Business users can then enable / disable and add dictionary items for this dictionary on the user side.
[0130] Standard Field Management: The field list under a single entity, where information such as field name, field key, field type, and whether the field is defined in the code can be viewed, and the fields can be filtered. At the same time, the field list can be displayed in a paged manner in this list, and the number of items per page can be switched. It supports searching and displaying according to the identifier of the entity and also supports searching and displaying according to the name of the entity. Reset the search conditions in the list to restore the list display. It supports online addition of fields to visually expand the existing fields of related services, and the extended configuration can be modified online, such as adding enumeration items for enumeration fields. The resource items of a field allow corresponding to multiple sets of configured entity resources to meet the needs of business secondary development. It is possible to switch field resources online. Support checking the resources in the list and batch disabling them, and the relevant resources will no longer be effective. The list supports customizing the displayed columns, controlling the visibility and order of the columns, customizing the filtering rules of the list, and storing them as filters for convenient secondary filtering. Quickly use and switch filters to quickly filter the list.
[0131] Model Designer: In the designer relationship diagram, the entity details can be quickly opened, in the form of a combination of a diagram and a table, to achieve the purpose of quickly browsing and modifying. On the entity relationship diagram, quickly call out the entry to view / modify the entity. Clicking on the selected entity and editing will jump to the corresponding entity information editing page. On the entity relationship diagram, quickly call out the entry to add / modify the field configuration in the entity. Clicking on the selected entity field and editing will jump to the corresponding entity field editing page.
[0132] Version Management: Strictly control and manage the versions of the models to ensure that each release is a stable version that has been fully tested and verified.
[0133] Transport Layer Management: View all GraphQL interfaces, and list all GraphQLs in a list in the order of invocation. Multiple requests with different parameters but the same structure will be merged into a single interface, so it is possible to intuitively see how many GraphQLs are currently running in the system. View the basic information, request records, and statistical information of the interfaces. Clicking on a single interface will enter the interface details page, where all specific requests of this interface will be displayed, including its request parameters. At the same time, the number of invocations and the average response time will also be displayed. When it is found that the average execution time of a certain interface is too slow to meet the business requirements, the interface optimization can be performed through this function, and the model structure corresponding to this interface can be generated into a search group and imported into the search engine with one click.
[0134] Attribute Management: Used to describe a certain characteristic of a data object or the location of storing data items. Each attribute has a unique name and data type, as well as possible other characteristics, such as length, whether null is allowed, etc. It mainly includes attribute naming specifications, data type management, attribute length and precision management, attribute constraint management, attribute index management, attribute permission management, etc.
[0135] Combined with the above statements, the DataStore in this application provides data access capabilities based on model metadata, shields the differences in storage media, and can use a consistent GraphQL protocol API to access search, relational databases, and distributed caches. The DataStore is driven by model metadata to change the internal storage structure, automatically migrates data for secure structure changes, generates DDL review sheets for insecure structure changes, and releases them after review or manual changes. The model capability engine provides general model CRUD capabilities based on model metadata, and at the same time performs read and write control at the data row and column levels based on data permission configurations (implemented by rewriting GraphQL). The model capability engine itself is stateless and can be infinitely horizontally scaled as needed, providing a unified service to the upper layer through the gateway.
[0136] The model engine drives storage, data services, and page interactions in a way driven by the metadata model, achieving isolation between the data logic layer and the physical layer. Model orchestration no longer directly defines database tables, but defines logical models with business meanings and the relationships between models. Subsequent adjustments to the models will synchronize these changes at the system global level, affecting the storage layer, data services, and page interactions. This model orchestration capability realizes the isolation between logical definition and physical definition, provides a model orchestration method for the visual console, and also provides a model orchestration method at the code level for the convenience of developers. The visual method is more flexible and can take effect immediately without code deployment operations, but for more complex logical processing, it can be orchestrated and assembled through the code implementation method. The two methods can be mixed as needed to provide a more powerful orchestration capability.
[0137] It can be seen from the above embodiments that the method for model orchestration described in the embodiments of this application, in response to the model orchestration requirement, uses the model orchestration engine to define the business model to obtain metadata; uses the metadata management module to receive the metadata and automatically generate the storage structure; based on the metadata, uses the data access module to provide a data access interface for the page interaction orchestration module; uses the page interaction orchestration module to automatically generate orchestration components based on the data information stored in the data access module to complete model orchestration. Model orchestration no longer directly defines database tables, but defines logical models with business meanings and the relationships between models. Subsequent adjustments to the models will synchronize these changes at the system global level, affecting the storage layer, data services, and page interactions. This model orchestration capability realizes the isolation between logical definition and physical definition. This orchestration capability provides a model orchestration method for the visual console, and also provides a model orchestration method at the code level for the convenience of developers. The visual method is more flexible and can take effect immediately without code deployment operations, but for more complex logical processing, it can be orchestrated and assembled through the code implementation method. The two methods can be mixed as needed to provide a more powerful orchestration capability.
[0138] It should be noted that the method of the embodiments of the present application can be executed by a single device, such as a computer or a server, etc. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In such a distributed scenario, one of the multiple devices can only execute one or more steps of the method of the embodiments of the present application, and these multiple devices will interact with each other to complete the described method.
[0139] It should be noted that some embodiments of the present application have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the above embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0140] Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present application further provides a model orchestration system.
[0141] Refer to Figure 3 , the model orchestration system includes: a model orchestration engine, a metadata management module, a data access module, and a page interaction orchestration module;
[0142] The model orchestration engine is configured to define a business model in response to the model orchestration requirement to obtain metadata;
[0143] The metadata management module is configured to receive the metadata and automatically generate a storage structure;
[0144] The data access module is configured to provide a data access interface for the page interaction orchestration module based on the metadata;
[0145] The page interaction orchestration module is configured to automatically generate an orchestration component based on the data information stored in the data access module to complete model orchestration.
[0146] For convenience of description, when describing the above system, it is divided into various modules according to functions and described separately. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.
[0147] The system described in this description is an efficient development platform based on Domain-Driven Design (DDD), and its core lies in the "model orchestration engine". The following is a detailed description of the system architecture, the functions of each module, and its data interaction closed loop.
[0148] Overall System Architecture:
[0149] The entire system is divided into the following main modules. Each module operates independently and collaboratively, forming a complete functional loop from model definition to data access to page interaction:
[0150] Model Orchestration Engine:
[0151] Core Function: Responsible for online model definition and relationship orchestration between models, and supports decoupling of logical models and physical storage structures.
[0152] Data Flow: Drives the metadata management module, data access module, and page interaction module.
[0153] Metadata Management Module:
[0154] Core Function: Manages model metadata, including model fields, relationship types, metadata versions, etc., and provides a unified metadata storage and update mechanism.
[0155] Data Flow: Provides metadata to the model orchestration engine, data access module, and page interaction module.
[0156] Data Access Module:
[0157] Core Function: Based on model metadata, shields the differences in storage media, provides a unified data access interface (such as GraphQL), and supports data change and permission control.
[0158] Data Flow: Obtains model definitions from the metadata management module, processes data access requests, and returns data to the page interaction module or other services.
[0159] Page Interaction Orchestration Module:
[0160] Core Function: Dynamically generates interface display and interaction logic according to the defined model and metadata, reducing the interface writing work of developers.
[0161] Data Flow: Obtains definitions from the model orchestration engine and metadata management module, and obtains data from the data access module.
[0162] Detailed Function Description and Data Flow of the Module:
[0163] Model Orchestration Engine:
[0164] Function Description:
[0165] Model Definition: Supports users to define domain models (entities, value objects, aggregates, aggregate roots, etc.) and their relationships through an online visual interface or code annotation.
[0166] Model Relationships: Support defining one-to-one, one-to-many, many-to-many, etc. relationships between models, and support the reference and mapping of domain models.
[0167] Model Change Propagation: When the user adjusts the model definition, the model orchestration engine generates change events, automatically synchronizes them to the metadata management module, and triggers data migration or code updates.
[0168] Code Generation: Dynamically generate domain service code frameworks, data access frameworks, and logic layer code through model definitions.
[0169] Data Interaction Process:
[0170] The user defines the model in the model orchestration interface, and the operations are saved in memory.
[0171] After the model definition entry is submitted, the model orchestration engine submits the model and its related metadata to the metadata management module for unified storage.
[0172] The engine compiles the model definition into a code framework (such as CRUD services, interface classes, etc.) and deploys it to the data access module or page interaction module through the build service.
[0173] Metadata Management Module:
[0174] Function Description:
[0175] Metadata Storage: Provide a unified metadata storage structure to store information such as models, fields, relationships, permissions, etc.
[0176] Version Management: Support versioned storage of metadata to ensure the traceability and historical management of model changes.
[0177] Change Management: Parse model change events and generate relevant DDL statements or other change operations.
[0178] Permission Control: Define row-level and column-level permissions for data access through metadata records.
[0179] Data Interaction Process:
[0180] Receive the model definition submitted by the model orchestration engine and parse it into metadata entries for storage.
[0181] After the metadata changes, trigger an event to notify the data access module to perform data structure changes (such as generating DDL) or trigger the page interaction module to adjust the interface display.
[0182] Push the permission configuration to the data access module to control the read and write permissions of data.
[0183] Data Access Module:
[0184] Function Description:
[0185] Data access interface: Provide GraphQL API to support unified access to structured (database), unstructured data (such as search engines), and caches.
[0186] Storage separation: Mask the underlying storage differences and support multiple storage media (such as relational databases, distributed caches, etc.).
[0187] Data migration: Based on metadata-driven data structure changes (such as adding fields), support automatic migration of safe changes and DDL audits of unsafe changes.
[0188] Permission control: According to metadata configuration, implement row-level and column-level permission control, and filter data by rewriting query statements.
[0189] Data interaction process:
[0190] Load metadata from the metadata management module, including model structure and permission rules.
[0191] Generate a unified GraphQL interface according to the metadata for access by the page interaction module or other clients.
[0192] Perform permission verification on data access requests, and filter fields or data rows that are not allowed to be accessed for different users.
[0193] When performing query or write operations, mask the differences in storage implementations and return results uniformly.
[0194] Page interaction orchestration module:
[0195] Function description:
[0196] Dynamic interface generation: Dynamically generate interface components (such as forms, lists, data charts, etc.) according to model definitions.
[0197] Interface logic association: Support mapping the business logic of the domain model to interface interactions, reducing manual coding.
[0198] Model change synchronization: When the model definition changes, the interface is automatically updated to reflect the latest structure.
[0199] Hybrid mode support: Support both automatic interface generation and flexible adjustment by developers based on code.
[0200] Data interaction process:
[0201] Obtain the model structure from the model orchestration engine or metadata management module to generate interface interaction logic.
[0202] The dynamic data is obtained by calling the GraphQL interface from the data access module and presented on the interface.
[0203] After the user operation submits data, it is passed back to the data access module through the page interaction module for data writing.
[0204] Through the collaborative work of the above modules, the system realizes a complete closed-loop from model definition to data storage to interface interaction:
[0205] Model definition: The domain architect defines the domain model and its relationships through the model orchestration engine, and the model definition is submitted to the metadata management module for storage.
[0206] Metadata synchronization: The metadata management module generates a set of unified metadata based on the model definition and pushes it to the data access module and the page interaction module.
[0207] Data access: The data access module provides a unified GraphQL interface based on the metadata to implement data reading, writing, and permission control.
[0208] Page interaction: The page interaction module generates the interface based on the model definition and obtains and presents the data through the data access module.
[0209] Model adjustment: When the model definition changes, the model change event is propagated to the data access module and the page interaction module through the metadata management module, automatically adjusting the storage structure and interface layout to ensure the consistency of the system.
[0210] Furthermore, the additional functions in the system are described:
[0211] Cross-platform support:
[0212] The data access module supports multiple storage engines (such as MySQL, PostgreSQL, Redis, etc.) and has good cross-platform compatibility.
[0213] High availability:
[0214] The model engine and the data access module are statelessly designed and support horizontal scaling.
[0215] Security:
[0216] Supports fine-grained permission control based on fields and data rows to ensure the security of sensitive data.
[0217] Collaborative development:
[0218] Visual model orchestration improves team collaboration efficiency and supports simultaneous use by R & D personnel and architects.
[0219] This system realizes the deep collaboration between design and R & D in a model-driven manner, significantly improving the development efficiency and system flexibility, while ensuring the consistency of architecture and code implementation.
[0220] The system of the above embodiment is used to implement the corresponding model orchestration method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.
[0221] Those of ordinary skill in the art should understand that the discussion of any of the above embodiments is only exemplary and is not intended to imply that the scope of the present application (including the claims) is limited to these examples; under the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of brevity.
[0222] The embodiments of the present application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the embodiments of the present application shall be included within the protection scope of the present application.
Claims
1. A model orchestration method, characterized in that, Applied to a model orchestration system, the model orchestration system includes: a model orchestration engine, a metadata management module, a data access module, and a page interaction orchestration module; The method includes: In response to the model orchestration requirement, using the model orchestration engine to define a business model and obtain metadata; Using the metadata management module to receive the metadata and automatically generate a storage structure; Based on the metadata, using the data access module to provide a data access interface for the page interaction orchestration module; Using the page interaction orchestration module to automatically generate an orchestration component based on the data information stored in the data access module to complete model orchestration.
2. The method according to claim 1, characterized in that The using the model orchestration engine to define a business model and obtain metadata includes: Using the model orchestration engine to define entities and entity relationships in the business model to obtain the metadata.
3. The method according to claim 1, characterized in that The based on the metadata, using the data access module to provide a data access interface for the page interaction orchestration module includes: Based on the metadata, using the data access module for dynamic query and data operation data logic; Based on the data logic, providing a data access interface for the page interaction orchestration module.
4. The method according to claim 3, characterized in that, The based on the data logic, providing a data access interface for the page interaction orchestration module includes: Based on the data logic, providing a data access interface for the page interaction orchestration module through the GraphQL protocol.
5. The method according to claim 1, wherein The method further includes: In response to a data change event, using the metadata management module to synchronize the first change data corresponding to the data change event to the data access module.
6. The method according to claim 5, characterized in that The method further includes: In response to data changes in the data access module, the page interaction orchestration module automatically changes component orchestration based on the data changes to complete the update of model orchestration.
7. The method according to claim 5, wherein The method further includes: judging the security of the change event; In response to the change event being insecure, generating a data definition language review form based on the change event; In response to the review form passing the review, continuing to process the change event.
8. The method according to claim 1, wherein The method further includes: Based on the data permissions in the model orchestration requirement, using the metadata management module to limit the access permissions to the metadata.
9. The method according to claim 1, characterized in that, The method further includes: In response to a direct change event to the orchestration component, using the page interaction orchestration module to synchronize the second change data corresponding to the direct change event of the orchestration component to the data access module.
10. A system for model orchestration, characterized in that, Includes: A model orchestration engine, a metadata management module, a data access module, and a page interaction orchestration module; The model orchestration engine is configured to, in response to the model orchestration requirement, define a business model and obtain metadata; The metadata management module is configured to receive the metadata and automatically generate a storage structure; The data access module is configured to, based on the metadata, provide a data access interface for the page interaction orchestration module; The page interaction orchestration module is configured to automatically generate an orchestration component based on the data information stored in the data access module to complete model orchestration.