Product extension method based on domain design mode

Abstract

The invention discloses a product extension method based on a domain design mode, and the method comprises the steps: constructing a domain general framework according to the demands of a specific domain; based on the domain general framework, a platform independent model is defined, and the platform independent model comprises a domain general PIM and an enterprise special PIM; converting the platform-independent model into codes based on a code generator FCG of a domain general framework; and adjusting or expanding the field general PIM code and the enterprise special PIM code according to the new business requirement or function requirement to realize product expansion. And the consistency and maintainability of codes are ensured.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a product expansion method based on a domain design pattern. Background Art

[0002] In modern software development, product expansion is a key task, especially when software applications face ever-changing business needs. It is crucial to be able to quickly expand and flexibly adjust the product's architecture and functions. When faced with complex business scenarios and changing user needs, traditional software architecture cannot support flexible expansion well, the development process can easily become cumbersome, and the system's performance and maintainability may also be affected.

[0003] Domain-Driven Design (DDD) provides a systematic way of thinking to help developers understand the core concepts of the business domain and design and implement software architecture accordingly. By mapping complex business problems into software models, DDD helps to closely integrate business and technology and achieve more efficient product expansion. However, although DDD has wide applicability in theory, in the actual development process, it often faces the following problems:

[0004] Cumbersome development process: DDD lacks specific implementation details and tool support. In actual applications, developers often need to manually build a large number of domain models, services, and infrastructure, resulting in a long development cycle and low efficiency. Poor program performance: In some implementation processes, the complexity of the domain model leads to performance bottlenecks, especially in the data access layer, cache mechanism, query optimization, etc. Unmanageable data and service layering: In the application of DDD, the management of domain models, data access, service layers, etc. becomes complicated. Without automated tool support, developers tend to ignore the principles of layered design, resulting in a chaotic system structure.

[0005] Therefore, there is an urgent need for a product extension method based on domain design patterns. Summary of the invention

[0006] The present invention provides a product expansion method based on a domain design pattern to solve the above problems existing in the prior art.

[0007] In order to achieve the above object, the present invention provides the following technical solutions:

[0008] Product extension methods based on domain design patterns include:

[0009] S101: Build a domain-wide framework based on the needs of a specific domain;

[0010] S102: Based on the domain-general framework, define platform-independent models, which include domain-general PIM and enterprise-specific PIM;

[0011] S103: A code generator FCG based on a domain-wide framework converts platform-independent models into code;

[0012] S104: According to new business requirements or functional requirements, adjust or expand the field-wide PIM code and the enterprise-specific PIM code to achieve product expansion.

[0013] Wherein, step S101 includes:

[0014] S1011: Obtain demand information in specific areas, including functional requirements, performance requirements, expansion requirements and user requirements;

[0015] S1012: Based on the demand information, determine the core components of the domain general framework, which include general data storage components, business logic processing components and user interface components;

[0016] S1013: Use the domain-driven design (DDD) method to design the core components in layers, dividing them into the domain layer, application layer, and infrastructure layer, and define the responsibilities and interaction methods of each layer;

[0017] S1014: For layered design, design the specific data model of each layer according to the concept of value objects in domain design, and assign corresponding implementation tasks to each core component;

[0018] S1015: Integrate demand information, core components, layered design and data model design results to build an overall architecture model of the domain-wide framework.

[0019] Wherein, step S102 includes:

[0020] Build the corresponding data model access program;

[0021] In the process of automatically building the data model access program, the automatic conversion program performs lexical analysis and syntax analysis on SQL and builds the corresponding SQL syntax tree;

[0022] In the domain-wide PIM, common functions and business logic are integrated to ensure that the platform-independent model has cross-domain versatility and adaptability;

[0023] Integrate the customized requirements of specific enterprises in enterprise-specific PIM to ensure that the platform-independent model can meet the personalized requirements of different enterprises;

[0024] Generate unified interface specifications based on domain-wide PIM and enterprise-specific PIM to ensure the compatibility and portability of platform-independent models between different platforms;

[0025] Adjust the implementation of the data model access program according to the generated unified interface specification;

[0026] Continuously optimize the platform-independent model and dynamically adjust the functional modules of the domain-general PIM and enterprise-specific PIM based on the feedback mechanism of the domain-general framework;

[0027] In the process of defining platform-independent models, corresponding data access strategies are dynamically generated in combination with the actual business scenarios of the enterprise to ensure efficient processing and secure management of data.

[0028] Wherein, step S103 includes:

[0029] The domain-general PIM and the enterprise-specific PIM are input into the code generator FCG, wherein the domain-general PIM and the enterprise-specific PIM respectively contain domain-specific metadata and enterprise-specific business rules;

[0030] The code generator FCG based on the domain-general framework parses the input domain-general PIM and enterprise-specific PIM to extract relevant metadata and business rules;

[0031] Use template engines or dedicated code generation tools to automatically generate entity classes, data access layer DAL and service interfaces in combination with the extracted metadata;

[0032] When generating entity classes, create corresponding class structures and attributes based on the metadata of the domain-wide PIM, and generate specific validation logic and business methods in combination with the business rules of the enterprise-specific PIM;

[0033] When generating the data access layer DAL, create data access interfaces and implementation classes based on the database mapping information of the domain-wide PIM, and generate custom query and data operation methods based on the specific data operation requirements of the enterprise-specific PIM;

[0034] When generating a service interface, create the corresponding interface definition based on the service contract of the domain-wide PIM, and generate a specific service implementation in combination with the business rules of the enterprise-specific PIM;

[0035] Based on the generated entity classes, data access layer DAL and service interface, a complete code structure is formed to convert the platform-independent model into executable code;

[0036] During the code generation process, user-defined extensions are supported, allowing users to add specific code snippets or modify the generation logic through configuration or plug-in mechanisms.

[0037] Wherein, step S104 includes:

[0038] Identify new business or functional requirements within the domain-wide framework, and determine the domain functional modules that need to be adjusted or expanded based on the identified requirements;

[0039] Based on the domain-wide framework, adjust or expand relevant codes to adapt to new business or functional requirements. The adjusted or expanded codes include enterprise-specific PIM codes and domain-wide PIM codes.

[0040] Use migration tools to synchronize database changes to ensure consistency of database structure and data content during expansion;

[0041] The integrated configuration center implements dynamic opening and closing of modular functions in the domain-wide PIM code and enterprise-specific PIM code, ensuring that new functions can be flexibly enabled or disabled as needed to meet actual business needs.

[0042] Among them, the core components of the domain-wide framework are determined, including:

[0043] According to the functional requirements, determine the core functional modules required by the domain general framework. The core functional modules are used to support the basic operations of the framework.

[0044] Based on performance requirements, evaluate and determine the data storage components required in the domain-wide framework. Data storage components are used to efficiently store, manage, and retrieve system data.

[0045] According to the expansion requirements, determine the business logic processing components in the domain general framework. The business logic processing components are used to support the scalability of the system.

[0046] Determine the user interface components of the domain-wide framework based on user needs. The user interface components are used to provide a friendly operation interface.

[0047] Integrate core functional modules, data storage components, business logic processing components and user interface components to form a domain-wide framework with high versatility and scalability.

[0048] Among them, the corresponding SQL syntax tree is constructed, including:

[0049] Perform lexical analysis on SQL statements to identify keywords, table names, field names and structures in SQL statements;

[0050] Based on the lexical analysis results, perform syntax analysis on the SQL statement, build the corresponding SQL syntax tree, and identify the query structure, conditional statements, connection relationships, etc. in the SQL statement;

[0051] Load configuration metadata from a data model metadata source that contains descriptions of tables, fields, relationships, and access rules;

[0052] According to the loaded configuration metadata, the SQL syntax tree is traversed, the nodes that need to be converted are replaced, and the original access target table is converted to a new target table;

[0053] Based on the replaced SQL syntax tree, traverse each node to construct the final access SQL.

[0054] The domain-wide PIM and enterprise-specific PIM that are analyzed and input include:

[0055] The code generator FCG is used to parse the domain-general PIM and enterprise-specific PIM structures, and the model information related to the domain-general framework and the customized information related to the enterprise business rules are extracted respectively;

[0056] Parse the domain-wide PIM and extract basic metadata:

[0057] Parse the domain-general PIM and extract the general metadata based on the modeling specifications of the domain-general framework. The metadata includes domain model definition, entity attributes, relationship model, service interface definition and interaction rules.

[0058] Parse enterprise-specific PIM and extract customized business rules:

[0059] Based on the specific modeling rules of the enterprise-specific PIM, extract the business rules and customized extension information related to the enterprise's business needs;

[0060] Construct a joint meta-model based on domain-wide PIM and enterprise-specific PIM;

[0061] When building the joint metamodel, automatically check the logical consistency between the domain common framework and the enterprise business rules;

[0062] Extract key metadata based on the joint metamodel, build a dependency graph for model generation, and determine the dependency order required in the code generation process through the dependency graph;

[0063] Based on the joint metamodel and the extracted dependencies, the template engine module of the code generator is called to generate the corresponding code.

[0064] The customized extended information includes:

[0065] Enterprise-specific entity models and attribute information;

[0066] Rewrite rules for common rules in domain-wide PIM;

[0067] Specific service interaction processes, data mapping rules and constraints within the enterprise.

[0068] The dependency graph includes:

[0069] Call dependencies between service interfaces;

[0070] Constraint relationships between data entities;

[0071] The coverage relationship of customized business rules to the common domain model.

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

[0073] The product extension method based on the domain design pattern includes: building a domain-wide framework according to the needs of a specific domain; defining platform-independent models based on the domain-wide framework, including domain-wide PIM and enterprise-specific PIM; converting platform-independent models into codes based on the code generator FCG of the domain-wide framework; adjusting or extending the domain-wide PIM code and enterprise-specific PIM code according to new business needs or functional requirements to achieve product extension. Ensure code consistency and maintainability.

[0074] Other features and advantages of the present invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the present invention.

[0075] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0076] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0077] Figure 1 It is a flowchart of a product expansion method based on a domain design pattern in an embodiment of the present invention;

[0078] Figure 2 A flowchart of constructing a domain-general framework in an embodiment of the present invention;

[0079] Figure 3 It is a conceptual model diagram in an embodiment of the present invention. DETAILED DESCRIPTION

[0080] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0081] The embodiment of the present invention provides a product expansion method based on a domain design pattern, including:

[0082] S101: Build a domain-wide framework based on the needs of a specific domain;

[0083] S102: Based on the domain-general framework, define platform-independent models, which include domain-general PIM and enterprise-specific PIM;

[0084] S103: A code generator FCG based on a domain-wide framework converts platform-independent models into code;

[0085] S104: According to new business requirements or functional requirements, adjust or expand the field-wide PIM code and the enterprise-specific PIM code to achieve product expansion.

[0086] The working principle of the above technical solution is: build a general framework for the domain. At this stage, first of all, a general framework needs to be designed according to the needs of a specific business domain. This framework must cover the core concepts, business logic and infrastructure of the domain, and abstract these concepts and business logic so that they do not depend on specific platforms or technologies. Through this abstraction, the framework can support the implementation of multiple platforms. Domain modeling: determine core entities (such as customers, orders, products, etc.), value objects (such as customer addresses, product categories, etc.), aggregations (such as customer orders are aggregations of customers and orders), and domain services. Functional design: modularize different business functions to ensure their scalability and flexibility. For example, the customer management module includes functions such as customer information entry, query, and update, while the order management module includes functions such as order creation, delivery, and return. Technology stack selection: The general framework needs to support a variety of different platforms, such as databases, front-ends, back-ends, cloud platforms, etc. At this stage, these platforms and technology options are not locked, and the framework should be platform-independent.

[0087] Based on the domain-general framework, define a platform-independent model. The platform-independent model is an abstract layer that describes business logic and domain concepts, but does not involve specific technologies or platforms. This model can be divided into two parts: Domain-general PIM (Platform Independent Model): This is an abstract model common to all enterprises, applicable to multiple business scenarios, regardless of technical implementation. For example, the domain-general PIM defines entities such as "customer", "order", and "goods". Enterprise-specific PIM: Based on the specific needs and business scenarios of the enterprise, define the business model unique to the enterprise, including some enterprise-specific extended fields or functions. For example, for a manufacturing company, its dedicated PIM contains extended information related to supply chain management, such as "supplier", "purchase order", etc. Suppose you are developing a customer management system. The domain-general PIM includes the entity "customer", while the enterprise-specific PIM may add information such as "customer credit rating" and "customer region" according to the special needs of a certain industry.

[0088] The code generator (FCG) based on the domain-general framework converts the platform-independent model (PIM) into code that can be executed by a specific platform. This process includes: Design of the code generator: The code generator automatically converts the platform-independent model into code specific to a certain platform. For example, Java classes, database tables, API interfaces, etc. are generated. Model mapping and generation: Map entities, value objects, aggregates, etc. in the PIM model to the code structure of a specific platform. For example, the "customer" entity in the domain-general PIM will be converted into a Java class containing fields (such as customer ID, customer name, customer address) and corresponding methods (such as getters and setters). Assuming that an "order" entity is defined in the domain-general PIM, the code generator will automatically generate a Java class containing order-related attributes and methods based on this definition, and generate a database table to store order data.

[0089] As business needs or functional requirements change, domain-general PIM and enterprise-specific PIM need to be constantly adjusted and expanded to cope with the introduction of new functions or the optimization of existing functions. For example: Domain model expansion: According to new business needs, it is necessary to add new entities or value objects to the domain-general PIM, or modify the existing model. For example, if the "customer evaluation" function is introduced, it may be necessary to add a "customer evaluation" value object to the "customer" entity. Adjustment of enterprise-specific PIM: Further refine or add new functions and attributes according to the actual needs of the enterprise. For example, a company needs to add a "customer rating" field to the "order" entity to adapt to the new rating system. Automated code adjustment: The adjusted PIM model will regenerate new code through the code generator, and keep the code consistent with the domain model to ensure that the enterprise system can smoothly transition to new business needs.

[0090] The beneficial effects of the above technical solution are: through the platform-independent abstract model and code generator, developers do not need to manually write a lot of code, reducing the workload of manual code writing and ensuring the consistency and maintainability of the code. The design of the domain-general framework and PIM enables the system to be flexibly expanded according to business changes. New functions can be implemented by extending the PIM model, and the system code can be quickly updated through the code generator.

[0091] In another embodiment, step S101 includes:

[0092] S1011: Obtain demand information in specific areas, including functional requirements, performance requirements, expansion requirements and user requirements;

[0093] S1012: Based on the demand information, determine the core components of the domain general framework, which include general data storage components, business logic processing components and user interface components;

[0094] S1013: Use the domain-driven design (DDD) method to design the core components in layers, dividing them into the domain layer, application layer, and infrastructure layer, and define the responsibilities and interaction methods of each layer;

[0095] S1014: For layered design, design the specific data model of each layer according to the concept of value objects in domain design, and assign corresponding implementation tasks to each core component;

[0096] S1015: Integrate demand information, core components, layered design and data model design results to build an overall architecture model of the domain-wide framework.

[0097] Among them, the core components are designed in layers, including:

[0098] Identify the common data storage components and business logic processing components in the core components being traversed before;

[0099] Divide the general data storage components and business logic processing components into domain layers. If the division fails, the corresponding layer design is the infrastructure layer.

[0100] If there is a user interface component in the core component of the continuous detection, the user interface component is divided into the application layer;

[0101] Get the business rules and entities of the domain layer of the core component currently being traversed;

[0102] The business rules and entities of the domain layer are: the definition of business logic in the core components, the control of business processes, and the attributes and methods of entities;

[0103] Get the service interface of the application layer of the core component traversed previously;

[0104] The service interface of the application layer is: the application services defined in the application layer, the implementation of use cases, and the interaction with the domain layer;

[0105] Interactively match the business rules and entities of the domain layer with the service interfaces of the application layer to obtain a matching result matrix;

[0106] The matching result matrix is: a matrix obtained by filling the business rules and entities of the domain layer and the service interfaces of the application layer in the preset positions of the matrix according to the hierarchical structure;

[0107] Determine the interaction mode corresponding to the matching result matrix according to the matching result value of each element position of the matching result matrix and the preset interaction mode-responsibility comparison library corresponding to each element position;

[0108] The preset interaction mode-responsibility comparison library stores the correspondence between multiple matching result values ​​and interaction modes;

[0109] The interaction mode is: the calling relationship between the domain layer and the application layer, the data transmission method and the responsibility allocation;

[0110] If the interaction method meets the preset design specifications, the corresponding layer design is reasonable, otherwise the corresponding layer design is unreasonable;

[0111] Get the technical implementation details of the infrastructure layer of the core component currently being traversed;

[0112] The technical implementation details of the infrastructure layer are: data storage technology, network communication methods, and third-party service integration;

[0113] Perform technical matching between the service interface of the application layer and the technical implementation details of the infrastructure layer to obtain a technical matching result matrix;

[0114] The technology matching result matrix is: a matrix obtained by filling the service interface of the application layer and the technology implementation of the infrastructure layer in the preset positions of the matrix according to the technology type;

[0115] Determine the technology implementation method corresponding to the technology matching result matrix according to the matching result value of each element position of the technology matching result matrix and the preset technology implementation-infrastructure comparison library corresponding to each element position;

[0116] The preset technology implementation-infrastructure comparison library stores the correspondence between multiple technology matching result values ​​and technology implementation methods;

[0117] The technical implementation methods are: specific data access technology, message transmission mechanism and external system interface;

[0118] If the technical implementation method meets the preset technical specifications, the design of the corresponding infrastructure layer meets the requirements; otherwise, the design of the corresponding infrastructure layer does not meet the requirements;

[0119] Based on the design results of the domain layer, application layer, and infrastructure layer, comprehensively judge whether the layered design of the core components is reasonable;

[0120] If the comprehensive judgment result is reasonable layering, the core component layering design based on the domain-driven design (DDD) method is completed; otherwise, the responsibility allocation and interaction mode of each layer are readjusted until a reasonable layering design is achieved.

[0121] The working principle of the above technical solution is as follows: Figure 3 As shown in the figure, the conceptual model diagram determines the business objects and logical entities: first identify the main objects and entities involved in the business, such as customer master data, customer address information, etc. Define the relationship between entities: determine the relationship type between entities; use different colors to distinguish different types of objects and entities, such as business objects, logical entities, reference objects, etc.; add attribute information: add relevant attribute information to each entity to more clearly describe the characteristics of the entity. Verify and adjust the model: ensure that the model accurately reflects business needs, and adjust and optimize based on feedback.

[0122] Through communication with the business side, technical team, and end users, we sorted out the requirements for customer master data, including: customer master data needs to support creation, update, deletion, and query functions. The system needs to support high-concurrency customer data queries with a response time of less than 100 milliseconds. Customer classification and hierarchical management functions may be added in the future. The user interface should be intuitive and friendly, and support dynamic adjustment of fields.

[0123] Functional requirements include "customer data needs to support batch import" and performance requirements include "100,000 queries need to be supported per day".

[0124] Determine the core components of the domain-wide framework. Based on the demand information, identify the core components of the customer master data domain and build a domain-wide framework: Data storage components are used to store customer master data (such as customer ID, name, contact information, etc.). Select a database that supports efficient storage and fast retrieval (such as MySQL or MongoDB). Business logic processing components handle business logic such as customer classification, level division, and associated query. User interface components: Provide users with an interface for operating customer data, support input validation and interactive friendliness.

[0125] The core components are designed in layers using the domain-driven design (DDD) method. According to the DDD method, the core components are designed in layers, which are specifically divided into the following three layers:

[0126] Domain layer: defines the core business rules related to customer master data. For example, customers must have a unique ID and contact information cannot be empty. Application layer: defines how the system coordinates the interaction between the domain layer and the infrastructure layer. For example, it handles the "bulk import of customers" request initiated by the user. Infrastructure layer: handles specific data storage and transmission. For example, database operations and cache management. The responsibility of the application layer is to receive the "add new customer" request, call the domain layer logic to verify the validity of the data, and write to the database through the infrastructure layer.

[0127] According to the value object concept of DDD, design the data models of the domain layer, application layer and infrastructure layer: Domain layer: Design models that are highly related to business logic (such as the customer's "value object" contains customer ID, name, contact information, etc.). Application layer: Design a more abstract data transfer object (DTO, Data Transfer Object), which only contains necessary fields for cross-layer transmission. Infrastructure layer: Design data models related to storage technology (such as database table structure). For example: Value object model: CustomerValueObject (including customerId, name, phone fields). Data transfer object: CustomerDTO (used for API interface transmission). Database table structure: CustomerTable (fields include primary key, index, etc.).

[0128] Build the overall architecture model of the domain general framework, integrate demand information, core components, layered design and data model, and build the overall architecture model: Architecture model: Use a layered architecture diagram to show the complete process from user interface, application layer call, domain layer business logic processing to database storage. Detailed implementation: In the code implementation, clarify the responsibilities and interaction methods of each layer to ensure modular design and separation of responsibilities. In the architecture model, the user initiates a customer creation request through the interface component, the application layer distributes the request to the domain layer, and after the domain layer completes the business verification, it writes to the database through the infrastructure layer.

[0129] Among them, three types of components are identified and distinguished in the core components: General data storage components: used for data persistence, such as database tables, file storage, etc. Business logic processing components: define the core rules and operations of the system, such as order calculation logic. User interface components: provide users with interactive interfaces, such as web pages, mobile terminal display and operation. Core layer division: domain layer and application layer, domain layer: contains core business rules and entities, defines the main logic and behavior of the system. Business rules: business constraints or rules that the system must follow. Entity: a business object with a unique identifier and its attributes and methods. Application layer: defines application services and use cases, mainly responsible for: coordinating the business logic of the domain layer. Manage interactions with user interfaces or external systems.

[0130] Interaction matching: Domain layer and application layer, by interactively matching the business rules and entities of the domain layer with the service interfaces of the application layer, a matching result matrix is ​​generated. Matching process: Fill in the interaction points in the matrix according to the hierarchy (domain layer and application layer). Compare whether the interaction mode conforms to the preset interaction mode-responsibility comparison library. Interaction modes include: Call relationship: such as the application layer calls the domain layer to complete the calculation task. Data transfer mode: such as passing the information of the order entity through objects. Responsibility allocation: For example, business rules must belong to the domain layer.

[0131] Technology matching: Application layer and infrastructure layer, by matching the service interface of the application layer with the technical implementation details of the infrastructure layer, a technology matching result matrix is ​​generated. Technology matching process: Fill in the interaction points in the matrix according to the technology type (data storage, communication method, etc.). Compare whether it meets the preset technology implementation-infrastructure reference library. Technology implementation methods include: Data access technology: such as using SQL queries to access the database. Message delivery mechanism: such as using message queues (RabbitMQ) to deliver order update messages. External system interface: such as calling a third-party payment interface to complete payment.

[0132] For example, the service interface "Save Order" needs to store the order data in the database. The infrastructure layer uses SQL database technology. The technical matching verifies whether the application layer correctly calls the database access interface. Whether the database access meets the preset technical specifications (such as the use of ORM framework). If the implementation of the infrastructure layer does not meet the technical specifications (for example, directly concatenating SQL strings leads to security risks), the infrastructure layer design is considered unreasonable.

[0133] Comprehensively judge the layered design of core components based on: the interaction matching results between the domain layer and the application layer. The technical matching results between the application layer and the infrastructure layer. Make a comprehensive judgment: If all interactions and technical implementations meet the preset specifications, the layered design is reasonable. If there are any inconsistencies, the layered responsibility allocation or interaction method needs to be adjusted.

[0134] Iterate and adjust the layered design. If the layered design is unreasonable, you need to readjust the layer responsibilities. Modify unreasonable interaction methods (for example, adjust the business logic in the domain layer). Ensure that the responsibilities of each layer are clear, the interactions are standardized, and the technical implementation is reasonable.

[0135] The beneficial effects of the above technical solution are as follows: the domain-wide framework designed after analyzing the requirements can meet all business requirements for customer master data management, including dynamic expansion and high-performance support. It supports the addition of customer classification functions in the future, and the business only needs to expand the logic in the domain layer to reduce the impact on other modules. Through DDD layered design, the responsibilities of each layer are clarified, the coupling degree of the system is reduced, and the code is easier to maintain and expand. The separation of core components and the design of the value object model allow developers to implement each module in parallel and shorten the development cycle. The layered architecture model makes the system easy to expand and reduces the risk of system crashes caused by modifying a module.

[0136] In another embodiment, step S102 includes:

[0137] Build the corresponding data model access program;

[0138] In the process of automatically building the data model access program, the automatic conversion program performs lexical analysis and syntax analysis on SQL and builds the corresponding SQL syntax tree;

[0139] In the domain-wide PIM, common functions and business logic are integrated to ensure that the platform-independent model has cross-domain versatility and adaptability;

[0140] Integrate the customized requirements of specific enterprises in enterprise-specific PIM to ensure that the platform-independent model can meet the personalized requirements of different enterprises;

[0141] Generate unified interface specifications based on domain-wide PIM and enterprise-specific PIM to ensure the compatibility and portability of platform-independent models between different platforms;

[0142] Adjust the implementation of the data model access program according to the generated unified interface specification;

[0143] Continuously optimize the platform-independent model and dynamically adjust the functional modules of the domain-general PIM and enterprise-specific PIM based on the feedback mechanism of the domain-general framework;

[0144] In the process of defining platform-independent models, corresponding data access strategies are dynamically generated in combination with the actual business scenarios of the enterprise to ensure efficient processing and secure management of data.

[0145] The working principle of the above technical solution is: establish a mapping between logical entities and physical tables. In the traditional data access mode, developers need to directly operate the physical tables in the database (such as mdm_customers, mdm_customer_address, etc.). In the DDD mode, the system maps the physical tables to logical entities.

[0146] For example, suppose that in domain modeling, the following logical entities are defined:

[0147] Mdm_customers: Entity representing customer information.

[0148] Mdm_customer_address: An entity that represents customer address information.

[0149] Mdm_customer_manufacture: An entity that represents the manufacturing industry information to which the customer belongs.

[0150] Mdm_customer_company1: An entity that represents customer extended information for a project.

[0151] The logical entity is a business abstraction. Developers will not directly operate physical tables during the development process, but will access data through these logical entities.

[0152] Developers use logical entities to access data. Suppose developers want to query customer information, they can write the following SQL: Select * from mdm_customer_entity;

[0153] In this SQL, mdm_customer_entity is a logical entity. It does not directly correspond to a physical table, but is automatically converted into a corresponding physical table query by the program. The data tables involved include mdm_customers, mdm_customer_address and other tables.

[0154] The automatic conversion program will perform lexical analysis and syntax analysis on the SQL written by the developer and generate a SQL syntax tree. The syntax tree is a structured representation that shows the various components of SQL (such as selected fields, tables, connection conditions, etc.). For example, Select * from mdm_customer_entity; will be converted into the following form:

[0155] Select

[0156] *

[0157] From

[0158] mdm_customer_entity

[0159] The syntax tree does not directly correspond to a physical table, but serves as an abstract query structure.

[0160] Load configuration metadata and rewrite the syntax tree. The conversion program modifies the syntax tree according to the predefined configuration metadata (such as the mapping relationship between logical entities and physical tables). In this step, the program replaces the mdm_customer_entity logical entity with the corresponding physical tables mdm_customers and mdm_customer_address. This step actually converts the abstract query written by the developer into an actual database query. Assuming that the developer queries mdm_customer_entity, the system will automatically identify multiple physical tables of this entity, including mdm_customers and mdm_customer_address. Then, the program replaces mdm_customer_entity in the syntax tree with:

[0161] Select a.*,b.country_code,b.country_name

[0162] From mdm_customers a,

[0163] mdm_customer_address b

[0164] Where a.customer_id=b.customer_id;

[0165] Here a and b represent the mdm_customers and mdm_customer_address tables respectively, and customer_id is the association condition between them.

[0166] After traversing the rewritten syntax tree, the program will construct the final SQL query statement, as shown above. Developers do not need to manually write complex multi-table connection SQL, but only need to operate logical entities, and the system will generate the corresponding SQL as needed.

[0167] For more complex add, delete and modify operations, the system will follow similar logic, map the logical entity to a specific database table, and generate the corresponding SQL. For example, to add a new customer information, you can operate through the logical entity Mdm_customer, and the background program will automatically generate the corresponding INSERT SQL according to the configuration.

[0168] The beneficial effects of the above technical solution are: by using logical entities instead of directly operating physical tables, developers avoid manually writing complex SQL queries, especially in scenarios involving multi-table connections. The mapping relationship between logical entities and physical tables is handled by configuration and automated programs, and developers do not need to manually adjust information such as table names and field names in the SQL code. This makes the system easier to maintain, and when the table structure changes, the program will automatically adapt without the need for developers to manually modify it in each query. When migrating between different platforms, unified interface specifications and platform-independent models ensure cross-platform compatibility and portability. The DDD model emphasizes domain-driven, and the system closely integrates database access with business logic. Developers do not need to pay attention to the specific details of the database, but focus on the operation of the domain model. This way of decoupling business from database enables the system to respond to business changes more flexibly and support more complex business scenarios.

[0169] In another embodiment, step S103 includes:

[0170] The domain-general PIM and the enterprise-specific PIM are input into the code generator FCG, wherein the domain-general PIM and the enterprise-specific PIM respectively contain domain-specific metadata and enterprise-specific business rules;

[0171] The code generator FCG based on the domain-general framework parses the input domain-general PIM and enterprise-specific PIM to extract relevant metadata and business rules;

[0172] Use template engines or dedicated code generation tools to automatically generate entity classes, data access layer DAL and service interfaces in combination with the extracted metadata;

[0173] When generating entity classes, create corresponding class structures and attributes based on the metadata of the domain-wide PIM, and generate specific validation logic and business methods in combination with the business rules of the enterprise-specific PIM;

[0174] When generating the data access layer DAL, create data access interfaces and implementation classes based on the database mapping information of the domain-wide PIM, and generate custom query and data operation methods based on the specific data operation requirements of the enterprise-specific PIM;

[0175] When generating a service interface, create the corresponding interface definition based on the service contract of the domain-wide PIM, and generate a specific service implementation in combination with the business rules of the enterprise-specific PIM;

[0176] Based on the generated entity classes, data access layer DAL and service interface, a complete code structure is formed to convert the platform-independent model into executable code;

[0177] During the code generation process, user-defined extensions are supported, allowing users to add specific code snippets or modify the generation logic through configuration or plug-in mechanisms.

[0178] The working principle of the above technical solution is as follows: Domain-general PIM (Platform Independent Model): Domain-general PIM is a general model that is independent of a specific enterprise. It contains general business concepts, domain-specific metadata, and database mapping information. For example, customer master data (Customer Master Data) can include basic customer information, such as customer ID, name, address, contact information, etc. This information is applicable to multiple industries and enterprises, so there are no specific business rules in the domain-general PIM, and only the core concepts and data structures of the field are described. Enterprise-specific PIM: Enterprise-specific PIM expands the content of the domain-general PIM based on the specific needs and business rules of the enterprise. For example, a company may add specific validation rules to customer master data, such as the customer's credit rating, transaction history, etc. The purpose of enterprise-specific PIM is to customize the data and behaviors in the domain-general PIM in combination with the specific business needs of the enterprise.

[0179] Based on the domain-wide PIM and enterprise-specific PIM inputs, the code generator (FCG) will first parse the two PIM models. The parsing process includes: Extracting domain-specific metadata: such as customer ID, customer name, address, email and other fields and their types (string, integer, date, etc.). Extracting enterprise-specific business rules: For example, a company has specific requirements for customer credit ratings, requiring that the customer's credit rating must be within a specific range, or that some validation rules are required when creating a customer. FCG combines the data mapping information in the domain-wide PIM with the customized business rules in the enterprise-specific PIM to form the basis for code generation.

[0180] Template engine or dedicated code generation tool: FCG will use template engine or dedicated code generation tool to generate specific code based on the information extracted from PIM. The core of this process is the template engine, which defines how to generate entity classes, data access layer (DAL) and service interface code based on metadata through template files (such as freemarker or velocity).

[0181] According to the metadata in the domain-wide PIM, corresponding entity classes and attributes are created. For example, if a customer entity class (Customer) is defined in the PIM, it contains attributes such as CustomerId, CustomerName, Address, etc. At the same time, according to the business rules in the enterprise-specific PIM, validation logic and business methods are embedded in the generated entity class. For example, the enterprise may require that the customer name is not empty and must be in a specific format (such as only letters and spaces). FCG will automatically generate these validation rules in the entity class.

[0182] Generate data access interfaces and implementation classes based on the database mapping information in the domain-wide PIM. For example, if customer data is stored in the Customer table in the database, FCG will automatically generate a data access interface (such as ICustomerRepository) and its implementation class based on the field information provided in the PIM. Generate custom query methods based on the requirements of the enterprise-specific PIM. For example, if the enterprise needs to query customer information by customer credit level, FCG will generate specific query methods, such as findByCreditLevel(int level).

[0183] Generate service interface: Generate service interface based on the service contract in the domain-wide PIM. For example, a service interface ICustomerService may be generated, which includes methods such as creating customers, updating customer information, and querying customers. Generate service implementation class based on the business rules in the enterprise-specific PIM. In the implementation class, FCG will provide specific operation logic according to the business requirements of the enterprise, such as credit rating verification and address format verification when creating customers.

[0184] The generated code includes: entity classes, data access layer (DAL) and service interface. The code generator organizes these modules into a complete code structure. In this way, the platform-independent model (PIM) is converted into executable code through the code generator, and the enterprise can directly run and maintain these codes on its technical platform. Through configuration or plug-in mechanism, users can customize the code generation process. For example, users can specify the generation method of certain business methods through configuration files, or add specific code snippets, such as specific logging, transaction processing, etc. The plug-in mechanism can support the extension of the code generator's functions and add more customized functions, such as generating multi-language support, generating API documents, etc.

[0185] The beneficial effects of the above technical solution are: by automatically generating code, the workload of developers manually writing entity classes, data access layers and service interfaces is reduced. Developers only need to focus on the implementation of business logic without having to repeatedly write infrastructure code. Since the code is automatically generated based on standardized templates, it avoids problems such as inconsistent code style and repetitive errors that may occur when writing manually. All generated codes will comply with the conventions of the domain-general PIM and the business rules specific to the enterprise. The automatically generated code not only includes entity classes and data access layers, but also combines the business rules of the enterprise for customized generation. This ensures that the generated code meets business requirements and reduces the probability of human errors.

[0186] In another embodiment, step S104 includes:

[0187] Identify new business or functional requirements within the domain-wide framework, and determine the domain functional modules that need to be adjusted or expanded based on the identified requirements;

[0188] Based on the domain-wide framework, adjust or expand relevant codes to adapt to new business or functional requirements. The adjusted or expanded codes include enterprise-specific PIM codes and domain-wide PIM codes.

[0189] Use migration tools to synchronize database changes to ensure consistency of database structure and data content during expansion;

[0190] The integrated configuration center implements dynamic opening and closing of modular functions in the domain-wide PIM code and enterprise-specific PIM code, ensuring that new functions can be flexibly enabled or disabled as needed to meet actual business needs.

[0191] The working principle of the above technical solution is as follows: First, the enterprise will collect the requirements raised by the business department. These requirements may be the optimization of existing functions or the support of new business processes. Suppose the business department requires more flexible query and management of customer master data (such as customer contact information, purchase history, etc.). Specific requirements include support for new fields of customer data or refinement of customer classification. After the requirements are identified, they need to be analyzed and evaluated to confirm whether they fall within the scope supported by the general framework of the domain, or whether existing functional modules need to be adjusted. For example, if the demand for customer master data is compatible with the existing PIM (Product Information Management) system module, it can be achieved by adjusting the existing code.

[0192] Functional expansion: Based on the identified needs, the development team will make necessary adjustments or expansions to the existing functional modules in the domain-wide framework. These modules are generally universal and support different business scenarios. For example, the existing customer master data management module may lack support for the customer's "loyalty level" attribute. In this case, the customer master data module needs to be expanded to add this attribute.

[0193] Code extension: The extension work includes not only the adjustment of the domain-wide PIM code, but also the customized development of the enterprise-specific PIM code. The enterprise-specific PIM code is tailored to the specific needs of the enterprise, while the domain-wide PIM code is a universal code applicable to a variety of enterprise scenarios. If the enterprise decides to add a reporting function for customer master data, and this function is only required by the enterprise, then the enterprise-specific PIM code needs to be customized accordingly.

[0194] Database structure adjustment: When expanding functional modules, it usually involves modifying the database structure. For example, if you need to add a new "loyalty level" field to the customer master data, then the structure of the customer table in the database needs to add the corresponding field. Use migration tools (such as Flyway, Liquibase, etc.) to synchronize database changes to ensure that the database structure and data content are consistent with code changes.

[0195] Database content migration: After the structural adjustment, it is also necessary to ensure that the data in the database can adapt to the new structure. For example, the newly added fields need to be filled with default values ​​or data migration processing to ensure that the old data is not affected after the system upgrade.

[0196] Modular functions: In order to make the functions more flexible and controllable, the system usually integrates a configuration center. This configuration center allows dynamic management of different functional modules. Through configuration files or control panels, enterprises can enable or disable certain functions according to actual needs. Dynamic opening and closing: For example, in the process of expanding the customer master data management module, suppose that the new "loyalty level" function only needs to be enabled at a certain stage. At this time, the development team can enable the function in a specific time period through the configuration center, or disable the function at any time when customer needs change. This can be achieved by modifying the configuration file or calling the configuration center through the API.

[0197] The beneficial effects of the above technical solution are: through the combination of the domain-general framework and the enterprise-specific PIM code, the system can quickly adapt to different business needs. After integrating the configuration center, the enterprise can dynamically enable and disable functional modules in different scenarios. By utilizing the domain-general framework, many basic functions and logics can be reused, and the enterprise-specific parts only need to be customized on specific business logic. This greatly improves development efficiency and reduces unnecessary duplication of work.

[0198] In another embodiment, determining core components of a domain-general framework includes:

[0199] According to the functional requirements, determine the core functional modules required by the domain general framework. The core functional modules are used to support the basic operations of the framework.

[0200] Based on performance requirements, evaluate and determine the data storage components required in the domain-wide framework. Data storage components are used to efficiently store, manage, and retrieve system data.

[0201] According to the expansion requirements, determine the business logic processing components in the domain general framework. The business logic processing components are used to support the scalability of the system.

[0202] Determine the user interface components of the domain-wide framework based on user needs. The user interface components are used to provide a friendly operation interface.

[0203] Integrate core functional modules, data storage components, business logic processing components and user interface components to form a domain-wide framework with high versatility and scalability.

[0204] The working principle of the above technical solution is as follows: The core function module is the basic part of the general framework of the entire field, and it is responsible for supporting the basic operations of the system. According to the functional requirements, the core function module should cover the following content: Data input and output: For example, obtaining customer master data from the database, querying and modifying data. Security and permission control: Ensure that only authorized users can access or modify data. For example, different permissions can be set for users with different roles, such as administrators can modify all data, while ordinary users can only query data. Log management and monitoring: Record the system's operation log, monitor the system status, and ensure timely feedback and processing when an abnormality occurs. These modules ensure that the system can operate normally and meet business needs by providing basic functional support.

[0205] The data storage component is responsible for efficiently storing, managing, and retrieving data in the system. According to performance requirements, the data storage component needs to have: Efficient query and index mechanism: In order to ensure fast query and retrieval of data, database indexes or distributed storage systems can be used. For example, for customer master data, you can set up indexes to speed up queries based on customer IDs. Data persistence: that is, ensuring that data is not lost when the system crashes or restarts. Databases (such as relational databases MySQL, PostgreSQL) or NoSQL databases (such as MongoDB) are usually used to store data. Data backup and recovery mechanism: Back up data regularly to prevent data loss and support disaster recovery.

[0206] The business logic processing component supports the scalability and flexibility of the system. According to the expansion requirements, the business logic processing component should include: Modular design: split complex business processing into multiple modular components for easy expansion and maintenance. For example, customer master data processing may include multiple sub-modules, such as data validation, data conversion, data cleaning, etc. Interface design: integrate with other systems or modules by defining interfaces. For example, the framework can provide an API interface to allow external systems to read or write customer master data. Support plug-in mechanism: through plug-in design, support rapid access and customization of different business needs. For example, different processing rules can be provided for customers in different regions, and business functions can be flexibly expanded through the plug-in mechanism. User interface component: The user interface component provides a friendly operation interface so that users can interact with the system. According to user needs, the user interface component needs: Intuitive interface design: ensure that users can complete operations conveniently. For example, the system can provide a concise customer master data management interface, and users can easily query, edit and add customer data. Responsive design: enable the user interface to display normally on different devices (such as computers, tablets, and mobile phones). Interaction optimization: provide users with feedback mechanisms, such as displaying a progress bar when data is loaded, and giving clear prompts when the operation succeeds or fails.

[0207] After completing the design and implementation of the above modules, it is necessary to integrate the core functional modules, data storage components, business logic processing components and user interface components to form a complete domain-wide framework. The integration process requires: Interface uniformity: Ensure that the interfaces between components are compatible, and that components can interact through RESTful APIs or other communication mechanisms. Clear division of data flow and control flow: Data is input from the user interface, processed by the business logic component, saved by the data storage component, and finally fed back to the user through the interface. Performance optimization and testing: During the integration process, the system should be performance tested to ensure that the collaboration between components is efficient and bottleneck-free.

[0208] The beneficial effects of the above technical solution are: by establishing a domain-wide framework, the development team does not have to build applications from scratch every time, and can directly reuse the common functional modules that have been implemented in the framework. This can significantly shorten the development cycle and improve work efficiency. The modular design of the framework makes the system easier to maintain and expand. The modular design and plug-in mechanism of the business logic processing component allow the system to be flexibly expanded according to business needs.

[0209] In another embodiment, a corresponding SQL syntax tree is constructed, including:

[0210] Perform lexical analysis on SQL statements to identify keywords, table names, field names and structures in SQL statements;

[0211] Based on the lexical analysis results, perform syntax analysis on the SQL statement, build the corresponding SQL syntax tree, and identify the query structure, conditional statements, connection relationships, etc. in the SQL statement;

[0212] Load configuration metadata from a data model metadata source that contains descriptions of tables, fields, relationships, and access rules;

[0213] According to the loaded configuration metadata, the SQL syntax tree is traversed, the nodes that need to be converted are replaced, and the original access target table is converted to a new target table;

[0214] Based on the replaced SQL syntax tree, traverse each node to construct the final access SQL.

[0215] The working principle of the above technical solution is: the main task of lexical analysis is to convert SQL statements into a set of meaningful vocabulary units (Tokens), such as keywords, table names, field names, etc.

[0216] Parse SQL statements and extract keywords (such as SELECT, FROM, WHERE, JOIN, etc.). Identify table names, field names, etc. For example, in the SQL statement SELECT name, age FROM employees, employees is the table name, name and age are field names. Determine the structure of the SQL statement, such as the query part, filter condition part, join part, etc.

[0217] SELECT name,age FROM employees WHERE age>30

[0218] SELECT and FROM are key words.

[0219] employees is the table name.

[0220] name and age are the field names.

[0221] The age>30 after WHERE is the query condition.

[0222] Based on the tokens obtained from the lexical analysis, the parser will build the corresponding SQL syntax tree according to the SQL syntax rules. The nodes of the syntax tree represent the various components of SQL, such as query structure, conditions, connections, etc.

[0223] Analyze the statement and build a tree structure according to SQL syntax rules (such as the standard order of SELECT, FROM, WHERE). Identify the query part (such as SELECT name, age), data source (such as FROM employees), condition part (such as WHERE age>30) and other structures (such as connection conditions, sorting, etc.).

[0224] For the following SQL:

[0225] SELECT name,age FROM employees WHERE age>30

[0226] The root node of the syntax tree may be SELECT, and its child nodes include:

[0227] A columns node, containing the fields name and age;

[0228] A FROM node pointing to the table employees;

[0229] A WHERE node containing the condition age>30.

[0230] Configuration metadata contains descriptions of tables, fields, relationships, and data access rules. For example, a database table employees may contain fields id, name, age, and have a foreign key relationship with the departments table. Load configuration data about table structure, field information, and relationship descriptions from the metadata source. Metadata may be stored in JSON, XML, or database tables. Parse these configurations and generate corresponding metadata objects, such as table name, field name, field type, and relationship between tables.

[0231] According to the loaded configuration metadata, analyze each node in the syntax tree and replace the table name and field name with the new target table or field. Traverse the SQL syntax tree, identify the nodes that need to be converted (such as the target table or field), and replace them according to the metadata. For example, if the employees table is actually replaced by a new table staff, replace employees in the syntax tree with staff. When replacing, you also need to consider the compatibility and mapping relationship of the fields. For example, there may be no age field in the staff table, so you need to replace the query field from age to birthdate.

[0232] After the SQL syntax tree is replaced, traverse the modified syntax tree and regenerate the final SQL statement. Construct the final SQL statement based on the modified syntax tree. Ensure that the final SQL statement structure is correct, complies with SQL syntax rules, and can correctly access the target data table and field.

[0233] The beneficial effects of the above technical solution are: through lexical and grammatical analysis, table names and field names in SQL statements can be easily identified and replaced to adapt to changes in the system data model. By loading configuration metadata and automatically replacing them, it can ensure that the generated SQL statements always conform to the latest database model, avoiding errors and inconsistencies that may occur when manually modifying SQL statements. The system can generate SQL based on the latest metadata to ensure the accuracy and consistency of data access.

[0234] In another embodiment, parsing the input domain-general PIM and enterprise-specific PIM includes:

[0235] The code generator FCG is used to parse the domain-general PIM and enterprise-specific PIM structures, and the model information related to the domain-general framework and the customized information related to the enterprise business rules are extracted respectively;

[0236] Parse the domain-wide PIM and extract basic metadata:

[0237] Parse the domain-general PIM and extract the general metadata based on the modeling specifications of the domain-general framework. The metadata includes domain model definition, entity attributes, relationship model, service interface definition and interaction rules.

[0238] Parse enterprise-specific PIM and extract customized business rules:

[0239] Based on the specific modeling rules of the enterprise-specific PIM, extract the business rules and customized extension information related to the enterprise's business needs;

[0240] Construct a joint meta-model based on domain-wide PIM and enterprise-specific PIM;

[0241] When building the joint metamodel, automatically check the logical consistency between the domain common framework and the enterprise business rules;

[0242] Extract key metadata based on the joint metamodel, build a dependency graph for model generation, and determine the dependency order required in the code generation process through the dependency graph;

[0243] Based on the joint metamodel and the extracted dependencies, the template engine module of the code generator is called to generate the corresponding code.

[0244] The working principle of the above technical solution is: PIM (Product Information Management) usually refers to a system used to centrally manage product information, usually covering various attributes and related metadata of products. Domain-wide PIM refers to a product information management architecture that is applicable to multiple business areas. This architecture defines the domain model and its structure in a standardized way, including entity definitions, attributes, relationship models, etc. The specific steps are as follows:

[0245] First, the system will parse the modeling specification of the domain-wide PIM. This specification defines all entities in the model and the relationships between them. For example, if we take customer master data as an example, the domain-wide PIM may define the "customer" entity and specify the basic attributes of the customer (such as: customer name, contact information, customer type, etc.). Next, the system will extract the attributes related to each entity. For example, the customer entity will include attributes such as "customer ID", "name", "address", and "telephone". Then, the system will parse out the relationships between entities. For example, the customer is associated with the "order" entity, indicating that a customer may have multiple orders.

[0246] Service interface definition and interaction rules: The system will extract the definition of service interfaces based on the domain-wide PIM. These interfaces are used for data interaction between different systems or modules. For example, an external system obtains customer data through the "query customer information" service interface, and the interaction rules will define the interface calling method, parameters, and return data format.

[0247] In enterprise-specific PIM, in addition to general domain modeling specifications, there may also be some customized extensions related to the business needs of specific enterprises. These extensions are defined by enterprises to adapt to their own business processes. For example, in some enterprises, customers may have a more complex classification system, or have a specific approval process in customer management.

[0248] Customized business rules: The system extracts rules related to the business needs of the enterprise based on the modeling specifications of the enterprise-specific PIM. For example, in customer management, the enterprise may define rules for customer credit rating and approval processes (for example, if a customer's credit score is below a certain threshold, the customer must be approved before the next transaction can proceed). Extended information: The system will further extract the enterprise's extended information for the domain-general PIM model. These extensions may include newly added entities or attributes. For example, the enterprise may add a "credit limit" attribute to the "customer" entity to indicate the customer's credit limit, or add a new "customer classification" attribute to classify customers according to their purchasing behavior.

[0249] Federated metamodel: In this step, the system integrates the metadata of the domain-general PIM and the enterprise-specific PIM into a "federated metamodel". This model not only includes the general business domain model, but also the enterprise-specific business extension part. In this way, it can be ensured that the enterprise-specific business needs can be effectively combined with the specifications in the general framework. For example, if the "customer" entity is defined in the domain-general PIM, and the "credit limit" attribute is newly added in the enterprise-specific PIM, then the federated metamodel will include these two parts, thereby ensuring that the customer data can meet both general and specific business needs.

[0250] Consistency check: After building the federated metamodel, the system automatically performs a consistency check. This is to ensure that there are no conflicts or inconsistencies between the specifications in the domain-wide PIM and the customized business rules in the enterprise-specific PIM. For example, if the domain-wide PIM stipulates that the customer ID is a required attribute, and the enterprise-specific PIM defines a special customer type that may not require a customer ID, the system will automatically detect this conflict and remind the relevant personnel to make adjustments.

[0251] Key metadata extraction: Based on the federated metamodel, the system extracts key metadata, which is crucial to the subsequent code generation process. For example, how customer data is stored, the validation rules for the data, etc. Dependency graph: The system builds a dependency graph by analyzing the entities, attributes, relationships, and business rules in the federated metamodel. The dependency graph shows the dependencies between various model elements when generating code. For example, a customer's order information may depend on the customer's basic information, so when generating code, the system needs to generate the customer entity code first, and then the order entity code.

[0252] Code generation: Finally, the system calls the template engine module of the code generator based on the joint metamodel and dependency graph to generate the corresponding code. The template engine automatically generates the required code based on the defined templates and metadata. For example, the system generates the structure of the database table, the code of the service interface, and the code of the validation rules based on the customer model.

[0253] The beneficial effect of the above technical solution is that the workload of manual code writing can be significantly reduced through the automated code generation process. Since the system can automatically generate code based on the metadata of the domain-general PIM and the enterprise-specific PIM, this greatly improves the efficiency and accuracy of code generation and avoids errors that may occur in the manual writing process. The system automatically verifies the logical consistency between the domain-general PIM and the enterprise-specific PIM to ensure that the specifications of the general framework are not violated while realizing the customized needs of the enterprise. This consistency check can reduce system errors or vulnerabilities caused by rule conflicts. The system can flexibly expand business rules and models according to the needs of the enterprise while maintaining consistency with the domain-general PIM framework.

[0254] In another embodiment, the customized extension information includes:

[0255] Enterprise-specific entity models and attribute information;

[0256] Rewrite rules for common rules in domain-wide PIM;

[0257] Specific service interaction processes, data mapping rules and constraints within the enterprise.

[0258] The working principle of the above technical solution is as follows: the enterprise-specific entity model is customized according to the business needs and operational characteristics of the enterprise, and is used to describe the core data entities (such as customers, products, orders, etc.) and their attributes involved in the enterprise's business. Demand analysis: First, conduct in-depth research and analysis on the business process of the enterprise to clarify which entities are the key elements in the core business of the enterprise. For example, taking customer master data as an example, the entity model may contain basic customer information (name, contact information, address, etc.), customer classification (VIP customers, ordinary customers, etc.) and customer historical transaction records. Model design: Define the entity model based on the needs, including the name, attributes, data type and its association relationship of the entity. For example, the customer entity may have a "one-to-many" relationship with the order entity. Data normalization: Set the fields according to the specifications of the database design to avoid redundancy. For example, use a unique customer number (such as "CustomerID") to identify the customer instead of directly using the customer name or other non-unique fields. Implementation and verification: Use data modeling tools (such as PowerDesigner or ER / Studio) to design the entity model, and then deploy it to the enterprise's database management system (such as MySQL, PostgreSQL, etc.) for testing.

[0259] The general rules in the domain-general PIM (platform-independent model) are usually data modeling rules shared in the industry or domain. These rules need to be rewritten and customized according to the actual business needs of the enterprise. Rule extraction: First, extract relevant general rules from industry standards or reference PIM models. For example, the general rule for customer data requires that "mobile phone numbers must be unique." Enterprise rewrite: Adjust the rules according to the specific needs of the enterprise. For example, for customer mobile phone numbers, it is required to verify both the area code and whether the number is registered within the enterprise. Rule mapping: Map the adjusted rules to the constraints of the enterprise database, such as implementing rule verification through database triggers or stored procedures. Testing and optimization: Verify the availability and stability of the rules in the development and test environment, and optimize the rules based on business feedback. For example, allow duplicate mobile phone numbers in certain business scenarios (such as sub-accounts of an enterprise account sharing mobile phone numbers).

[0260] The service interaction process within an enterprise refers to the specific way of exchanging data between different services in a distributed system. Data mapping rules define how to convert and transfer data between different systems or services. Service interaction process design: First, sort out the business processes and services involved within the enterprise. For example, the customer management system (CRM) needs to interact with the order management system (OMS) to ensure that the customer's credit limit can be queried when placing an order. Interface design: Define the communication protocol between services (such as REST API or SOAP) and determine the structure and format of the transmitted data. For example, define a data packet in JSON format, including customer number, order amount, etc. Data mapping rules: Determine the mapping relationship between fields in different systems. For example, the "CustomerID" field in CRM needs to be mapped to the "ClientID" in OMS. Constraints: Define the legitimacy check of the data. For example, the customer's credit limit must be greater than the order amount, otherwise the order processing is rejected. Testing and optimization: Use simulation tools (such as Postman or Swagger) to verify the correctness of the interface interaction and optimize the process in combination with actual scenarios.

[0261] The beneficial effects of the above technical solution are as follows: the customized entity model can more accurately describe the business entities of the enterprise, making data storage, query and analysis more efficient. It avoids the problem of inconsistent definitions and understandings of the same entity by different departments or systems, and reduces data redundancy and conflicts. The rewritten rules are more in line with the actual needs of the enterprise, ensuring that the system can adapt to the special scenarios of the enterprise.

[0262] In another embodiment, a dependency graph includes:

[0263] Call dependencies between service interfaces;

[0264] Constraint relationships between data entities;

[0265] The coverage relationship of customized business rules to the common domain model.

[0266] The working principle of the above technical solution is: sort out the services and their functions involved in the enterprise. For example, the Customer Master Data Service may need to provide the functions of querying, updating and deleting customer information, while the Order Management Service relies on the customer service to verify the customer status. Clarify the call chain between services. For example, the Order Management Service needs to call the customer service interface first to verify the customer's credit, and then call the inventory service interface to check the product inventory.

[0267] Dependency annotation: Use tools (such as Swagger or UML sequence diagrams) to describe dependencies. For example, annotate the order and dependency of the order management service, customer service, and inventory service. Implementation and optimization: Use microservice architecture tools (such as Spring Cloud, Apache Kafka) to implement calls, and optimize the performance of dependency calls through load balancing (such as Nginx or Ribbon).

[0268] Monitoring and adjustment: Use distributed tracing tools (such as Zipkin and Jaeger) to monitor the latency and failure rate of interface calls, identify performance bottlenecks, and adjust dependencies. For example, you can reduce the number of remote calls to frequently called dependent services through local caching.

[0269] Constraints between data entities refer to the rules that must be followed between different entities in the data model. For example, there is a foreign key constraint between customer master data and order data, which ensures that the customer mentioned in the order record must exist in the customer master data. Determine the logical relationship between entities. For example, there may be a "one-to-many" relationship between the customer entity and the order entity, and a customer can have multiple orders. Constraint definition: When designing the database, define foreign key constraints between entities. For example, in the order table, the CustomerID field must reference a valid customer record in the customer table. Complex constraint design: In addition to basic foreign key constraints, you can also design triggers or stored procedures to handle complex constraints. For example, the total amount of an order cannot exceed the customer's credit limit. Model validation: Use data modeling tools (such as ER / Studio) or database management tools (such as MySQLWorkbench) to validate the model to ensure the correctness of the constraint relationship. Continuous optimization: Adjust constraint rules as business needs change. For example, a new customer category may require additional validation constraints.

[0270] Customized business rules refer to the extension, modification or overwriting of industry-wide domain models (such as PIM) to better serve business needs based on the specific needs of the enterprise itself. Domain model analysis: Determine the basic rules and structures in the general domain model. For example, the customer master data model contains basic information fields for customers (such as name, address, and contact information). Requirements extraction: Extract the unique business needs of the enterprise. For example, an enterprise may need to add fields to customer information, such as customer referral information or customer preference tags. Override relationship definition: Define which rules or structures need to be overridden. For example, the general domain model stipulates that the "address" field is only allowed to store a single address, but the enterprise needs to allow multiple addresses to be stored. Implementation and integration: Use data modeling tools to implement the overridden model. For example, modify the customer master data model to increase the storage capacity of multiple addresses and use the JSON data type to support flexibility. Verification and release: Verify the overridden model through a test environment to ensure its compatibility with the business system. Discuss with domain experts whether adjustments are needed when necessary.

[0271] The beneficial effects of the above technical solution are: through clear interface call dependency design, automated business processing across services is achieved. Clear dependencies and optimized call paths reduce the possibility of interface call failures and data errors. Through dependency optimization and load balancing, the delay in inter-service calls is reduced and the overall system response speed is improved. Through mechanisms such as foreign key constraints and triggers, the consistency of the relationships between entities in the data model is ensured. Automatic constraint relationships reduce the need for manual intervention, such as avoiding isolated data due to misoperation. Clear relationships between entities make business logic easier to understand and facilitate system maintenance and expansion. Customized rules enable the model to fully adapt to the specific business scenarios of the enterprise,

[0272] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A product extension method based on domain design pattern, characterized in that: include: S101: Build a domain-wide framework based on the needs of a specific domain; S102: Based on the domain-general framework, define platform-independent models, which include domain-general PIM and enterprise-specific PIM; S103: A code generator FCG based on a domain-wide framework converts platform-independent models into code; S104: According to new business requirements or functional requirements, adjust or expand the field-wide PIM code and the enterprise-specific PIM code to achieve product expansion.

2. The product expansion method based on domain design pattern according to claim 1 is characterized in that: Step S101 includes: S1011: Obtain demand information in specific areas, including functional requirements, performance requirements, expansion requirements and user requirements; S1012: Based on the demand information, determine the core components of the domain general framework, which include general data storage components, business logic processing components and user interface components; S1013: Use the domain-driven design (DDD) method to design the core components in layers, dividing them into the domain layer, application layer, and infrastructure layer, and define the responsibilities and interaction methods of each layer; S1014: For layered design, design the specific data model of each layer according to the concept of value objects in domain design, and assign corresponding implementation tasks to each core component; S1015: Integrate demand information, core components, layered design and data model design results to build an overall architecture model of the domain-wide framework.

3. The product expansion method based on domain design pattern according to claim 1 is characterized in that: Step S102 includes: Build the corresponding data model access program; In the process of automatically building the data model access program, the automatic conversion program performs lexical analysis and syntax analysis on SQL and builds the corresponding SQL syntax tree; In the domain-wide PIM, common functions and business logic are integrated to ensure that the platform-independent model has cross-domain versatility and adaptability; Integrate the customized requirements of specific enterprises in enterprise-specific PIM to ensure that the platform-independent model can meet the personalized requirements of different enterprises; Generate unified interface specifications based on domain-wide PIM and enterprise-specific PIM to ensure the compatibility and portability of platform-independent models between different platforms; Adjust the implementation of the data model access program according to the generated unified interface specification; Continuously optimize the platform-independent model and dynamically adjust the functional modules of the domain-general PIM and enterprise-specific PIM based on the feedback mechanism of the domain-general framework; In the process of defining platform-independent models, corresponding data access strategies are dynamically generated in combination with the actual business scenarios of the enterprise to ensure efficient processing and secure management of data.

4. The product expansion method based on domain design pattern according to claim 1, characterized in that: Step S103 includes: The domain-general PIM and the enterprise-specific PIM are input into the code generator FCG, wherein the domain-general PIM and the enterprise-specific PIM respectively contain domain-specific metadata and enterprise-specific business rules; The code generator FCG based on the domain-general framework parses the input domain-general PIM and enterprise-specific PIM to extract relevant metadata and business rules; Use template engines or dedicated code generation tools to automatically generate entity classes, data access layer DAL and service interfaces in combination with the extracted metadata; When generating entity classes, create corresponding class structures and attributes based on the metadata of the domain-wide PIM, and generate specific validation logic and business methods in combination with the business rules of the enterprise-specific PIM; When generating the data access layer DAL, create data access interfaces and implementation classes based on the database mapping information of the domain-wide PIM, and generate custom query and data operation methods based on the specific data operation requirements of the enterprise-specific PIM; When generating a service interface, create the corresponding interface definition based on the service contract of the domain-wide PIM, and generate a specific service implementation in combination with the business rules of the enterprise-specific PIM; Based on the generated entity classes, data access layer DAL and service interface, a complete code structure is formed to convert the platform-independent model into executable code; During the code generation process, user-defined extensions are supported, allowing users to add specific code snippets or modify the generation logic through configuration or plug-in mechanisms.

5. The product expansion method based on domain design pattern according to claim 1, characterized in that: Step S104 includes: Identify new business or functional requirements within the domain-wide framework, and determine the domain functional modules that need to be adjusted or expanded based on the identified requirements; Based on the domain-wide framework, adjust or expand relevant codes to adapt to new business or functional requirements. The adjusted or expanded codes include enterprise-specific PIM codes and domain-wide PIM codes. Use migration tools to synchronize database changes to ensure consistency of database structure and data content during expansion; The integrated configuration center implements dynamic opening and closing of modular functions in the domain-wide PIM code and enterprise-specific PIM code, ensuring that new functions can be flexibly enabled or disabled as needed to meet actual business needs.

6. The product expansion method based on domain design pattern according to claim 2 is characterized in that: Identify the core components of a domain-wide framework, including: According to the functional requirements, determine the core functional modules required by the domain general framework. The core functional modules are used to support the basic operations of the framework. Based on performance requirements, evaluate and determine the data storage components required in the domain-wide framework. Data storage components are used to efficiently store, manage, and retrieve system data. According to the expansion requirements, determine the business logic processing components in the domain general framework. The business logic processing components are used to support the scalability of the system. Determine the user interface components of the domain-wide framework based on user needs. The user interface components are used to provide a friendly operation interface. Integrate core functional modules, data storage components, business logic processing components and user interface components to form a domain-wide framework with high versatility and scalability.

7. The product expansion method based on domain design pattern according to claim 3 is characterized in that: Construct the corresponding SQL syntax tree, including: Perform lexical analysis on SQL statements to identify keywords, table names, field names and structures in SQL statements; Based on the lexical analysis results, perform syntax analysis on the SQL statement, build the corresponding SQL syntax tree, and identify the query structure, conditional statements, connection relationships, etc. in the SQL statement; Load configuration metadata from a data model metadata source that contains descriptions of tables, fields, relationships, and access rules; According to the loaded configuration metadata, the SQL syntax tree is traversed, the nodes that need to be converted are replaced, and the original access target table is converted to a new target table; Based on the replaced SQL syntax tree, traverse each node to construct the final access SQL.

8. The product expansion method based on domain design pattern according to claim 4 is characterized in that: Parse the input domain-wide PIM and enterprise-specific PIM, including: The code generator FCG is used to parse the domain-general PIM and enterprise-specific PIM structures, and the model information related to the domain-general framework and the customized information related to the enterprise business rules are extracted respectively; Parse the domain-wide PIM and extract basic metadata: Parse the domain-general PIM and extract the general metadata based on the modeling specifications of the domain-general framework. The metadata includes domain model definition, entity attributes, relationship model, service interface definition and interaction rules. Parse enterprise-specific PIM and extract customized business rules: Based on the specific modeling rules of the enterprise-specific PIM, extract the business rules and customized extension information related to the enterprise's business needs; Construct a joint meta-model based on domain-wide PIM and enterprise-specific PIM; When building the joint metamodel, automatically check the logical consistency between the domain common framework and the enterprise business rules; Extract key metadata based on the joint metamodel, build a dependency graph for model generation, and determine the dependency order required in the code generation process through the dependency graph; Based on the joint metamodel and the extracted dependencies, the template engine module of the code generator is called to generate the corresponding code.

9. The product expansion method based on domain design pattern according to claim 8, characterized in that: Customized extension information includes: Enterprise-specific entity models and attribute information; Rewrite rules for common rules in domain-wide PIM; Specific service interaction processes, data mapping rules and constraints within the enterprise.

10. The product expansion method based on domain design pattern according to claim 8, characterized in that: Dependency graph, including: Call dependencies between service interfaces; Constraint relationships between data entities; The coverage relationship of customized business rules to the common domain model.

Images