Data processing method and device based on domain drive design and electronic equipment

Abstract

The invention provides a data processing method and device based on domain-driven design and electronic equipment, and relates to the technical field of data processing, and the method comprises the steps: obtaining a warehouse interface of an aggregation warehouse, and determining an aggregation root entity and a value object associated with the warehouse interface; aggregating and generating a domain model according to the definition specifications of the aggregated root entity and the value object; mapping the domain model into a database relation meta-model, wherein the database relation meta-model represents the specific representation and composition of the domain model in the underlying database; and executing a data proxy operation for the underlying database based on the database relation meta-model. According to the method, the proxy implementation of the operation from the aggregation warehouse to the underlying database can be automatically completed, the situation that a developer manually configures and programs to complete mapping of the domain model to the database relationship is avoided, the development difficulty of the aggregation warehouse is reduced, and the working efficiency of the developer is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a data processing method, device and electronic device based on domain-driven design. Background Art

[0002] In Domain-Driven Design (DDD), an aggregate is a logical unit with high cohesion and low coupling, which includes entities and value objects, and only a unique entity is used as the aggregate root (i.e., the access point of the aggregate). An aggregate corresponds to a repository, which means that the repository is responsible for saving the domain objects in the aggregate to the persistent storage (database), ensuring the consistency of all objects in the aggregate, and supporting the retrieval of domain objects from the persistent storage.

[0003] Conventional implementations of aggregation warehouses mainly use the Object Relational Mapping (ORM) framework. All of them require the domain model to be decomposed into objects first, and then the objects, object relationships and database models are mapped through ORM. This process requires manual intervention by developers, and manual intervention requires developers to map the domain model to the object model by themselves, and then map the object model to the database relationship through the ORM framework (JPA / Hibernate, Mybatis, etc.). This involves: domain model->object model->database relationship model, and a domain model (such as an entity) usually corresponds to multiple objects and multiple database tables, which makes manual model conversion and mapping an extremely complex, tedious and fragmented process, which requires extremely high capabilities of developers, and because of the numerous details and conversions in the entire process, problems are very likely to occur, increasing the difficulty of development and maintenance. Summary of the invention

[0004] The present invention provides a data processing method, device and electronic device based on domain-driven design, which can automatically complete the proxy implementation of the operation from the aggregation warehouse to the underlying database, avoid the developer's manual configuration and programming to complete the mapping of the domain model to the database relationship, reduce the development difficulty of the aggregation warehouse, and improve the developer's work efficiency.

[0005] In a first aspect, a data processing method based on domain-driven design is provided, comprising: Get the repository interface of the aggregate repository, and determine the aggregate root entity and value object associated with the repository interface; Aggregate and generate domain models based on the definition specifications of aggregate root entities and value objects; Map the domain model to a database relational metamodel, which represents the specific representation and composition of the domain model in the underlying database; Execute data proxy operations on the underlying database based on the database relational metamodel.

[0006] In a second aspect, a data processing device based on domain-driven design is provided, comprising: Determine a module for obtaining a repository interface of an aggregate repository and determining aggregate root entities and value objects associated with the repository interface; The generation module is used to aggregate and generate domain models according to the definition specifications of aggregate root entities and value objects; A mapping module is used to map the domain model to a database relational metamodel, which represents the specific representation and composition of the domain model in the underlying database. The proxy module is used to perform data proxy operations on the underlying database based on the database relational metamodel.

[0007] According to a third aspect, an electronic device is provided, comprising: a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and run the computer program stored in the memory to execute the method in the first aspect or its various implementations.

[0008] According to a fourth aspect, a computer-readable storage medium is provided for storing a computer program, wherein the computer program enables a computer to execute the method according to the first aspect or its various implementations.

[0009] Through the technical solution provided by the present invention, after obtaining the warehouse interface of the aggregate warehouse, the aggregate root entity and value object associated with the warehouse interface can be determined; then, the domain model can be aggregated and generated according to the definition specifications of the aggregate root entity and value object; the domain model can be further mapped to the database relational metamodel; finally, the data proxy operation for the underlying database is performed based on the database relational metamodel. The technical solution in this application can automatically complete the proxy implementation of the operation from the aggregate warehouse to the underlying database. For developers, they can directly call the corresponding aggregate warehouse interface, which greatly reduces the difficulty of developing the aggregate warehouse and improves the work efficiency of developers.

[0010] It should be understood that the above general description and the following detailed description are only exemplary and explanatory and cannot limit the present invention. Other features and advantages of the present invention will be described in detail in the following specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0012] Figure 1 An application scenario diagram provided for an embodiment of the present application; Figure 2 A flowchart of a data processing method based on domain-driven design provided in an embodiment of the present application; Figure 3 A flowchart of a data processing method based on domain-driven design provided in another embodiment of the present application; Figure 4 A schematic diagram of an example of mapping a domain model to a database metamodel provided in an embodiment of the present application; Figure 5 A schematic diagram of the structure of a data processing device based on domain-driven design provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0014] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0015] In Domain-Driven Design (DDD), an aggregate is a logical unit with high cohesion and low coupling, which includes entities and value objects, and only a unique entity is used as the aggregate root (i.e., the access point of the aggregate). An aggregate corresponds to a repository, which means that the repository is responsible for saving the domain objects in the aggregate to the persistent storage (database), ensuring the consistency of all objects in the aggregate, and supporting the retrieval of domain objects from the persistent storage.

[0016] Conventional aggregation warehouses are mainly implemented using the Object Relational Mapping (ORM) framework. All of them require first breaking down the domain model into objects, and then mapping the objects, object relationships, and database models through ORM. This process requires developers to: 1) First, model the domain model 2) Then you need to complete the mapping of domain models, objects and database relationships This two-step development increases the workload of developers and the difficulty of program maintenance.

[0017] In step 2), the mapping of domain models to database relationships is mainly done using two methods: JPA (Hibernate) and MyBatis: The JPA method requires the use of cumbersome annotations (such as @Entity, @Embedded, @CollectionTable, @OneToMany, etc.) to map objects and relationships. Although it can well support complete object-relational mapping, its concepts are complex, the learning cost is high, and it has a very high entry threshold.

[0018] The MyBatis method is suitable for supporting object-relationship mapping of a single table. Faced with complex object relationships within an aggregate, a large amount of manual programming mapping of objects and relationships is required. The original object thinking of domain-driven design has to be converted into the underlying database thinking, which is cumbersome and violates the original intention of domain object modeling in object-oriented design and domain-driven design.

[0019] The above two methods require manual intervention by developers, and there is no fully automatic one. Manual intervention requires developers to map the domain model to the object model, and then map the object model to the database relationship through the ORM framework (JPA / Hibernate, Mybatis, etc.), which involves: domain model->object model->database relationship model, and a domain model (such as an entity) usually corresponds to multiple objects and multiple database tables, which makes manual model conversion and mapping an extremely complex, tedious, and fragmented process, requiring extremely high capabilities from developers, and because of the numerous details and conversions in the entire process, problems are very likely to occur, increasing the difficulty of development and maintenance.

[0020] In order to solve the above technical problems, the inventive concept of the present invention is to propose an aggregation warehouse implementation that can automatically complete the second step, avoiding developers from manually configuring and programming to complete the mapping of domain models to database relationships. In this way, developers can focus more on the development of domain models without having to worry about the adaptation of object models and ORM frameworks, greatly improving the development efficiency using domain-driven design.

[0021] It should be understood that the technical solution of the present invention can be applied to the following scenarios, but is not limited to: In some possible implementations, Figure 1 An application scenario diagram provided by an embodiment of the present invention, such as Figure 1 As shown, the application scenario may include an electronic device 110 and a network device 120. The electronic device 110 may establish a connection with the network device 120 via a wired network or a wireless network.

[0022] Exemplarily, the electronic device 110 may be a desktop computer, a laptop computer, a tablet computer, etc., but is not limited thereto. The network device 120 may be a terminal device or a server, but is not limited thereto. In one embodiment of the present invention, the electronic device 110 may send a request message to the network device 120, and the request message may be used to request to obtain a warehouse interface of the aggregate warehouse. Further, the electronic device 110 may receive a response message sent by the network device 120, and the response message includes the warehouse interface of the aggregate warehouse.

[0023] also, Figure 1 An electronic device 110 and a network device 120 are provided as an example, but other numbers of electronic devices and network devices may be included in practice, and the present invention is not limited thereto.

[0024] In some other possible implementations, the technical solution of the present invention may also be executed by the above-mentioned electronic device 110, or the technical solution of the present invention may also be executed by the above-mentioned network device 120, and the present invention does not limit this.

[0025] After introducing the application scenarios of the embodiments of the present invention, the technical solutions of the present invention will be described in detail below: Figure 2 A flowchart of a data processing method based on domain-driven design provided by an embodiment of the present invention, the method can be as follows Figure 1 The electronic device 110 shown in the figure performs, but is not limited to this. Figure 2 As shown, the method may include the following steps: Step 210: Obtain the warehouse interface of the aggregate warehouse, and determine the aggregate root entity and value object associated with the warehouse interface.

[0026] The repository interface of an aggregate repository refers to a design that aggregates multiple data sources or data access components when using the repository pattern. This design allows developers to access and operate different data stores through a unified interface, thereby simplifying the complexity of the data access layer. In the context of an aggregate repository, the repository interface usually defines a set of standard methods for performing data creation, deletion, modification, and query (CRUD) operations. The aggregate root is the entry point of the aggregate, and external access and operations on the aggregate need to be performed through the aggregate root. Value objects are objects without unique identifiers, and they are mainly used to describe certain characteristics or attributes. The aggregate root is an entity in the aggregate, which has a globally unique identifier, and is associated with the repository interface, and other entities and value objects in the aggregate depend on the aggregate root. Therefore, by parsing the repository interface, the aggregate root entity and value object associated with the repository interface can be determined.

[0027] Step 220: Aggregate and generate a domain model based on the definition specifications of the aggregate root entity and value object.

[0028] In a specific application scenario, a domain model definition specification module may be constructed, in which the definition specifications of entities and value objects in domain-driven design are pre-stored. The specification conforms to conventional domain-driven design and development practices, and may include the definition specifications of entities, value objects, value object sets, association identifiers, association identifier sets, etc., which are common in domain-driven design. For the embodiments of the present disclosure, the domain model may be automatically aggregated and generated according to the definition specifications of aggregate root entities and value objects stored in the domain model definition specification module.

[0029] Step 230: Map the domain model to a database relational metamodel, where the database relational metamodel represents the specific representation and composition of the domain model in the underlying database.

[0030] In specific application scenarios, a domain model relationship parsing module can be pre-built. The domain model relationship parsing module can parse the entities and value objects defined according to the requirements of the domain model definition specification module, and complete the automatic mapping of the domain model to the database relational metamodel.

[0031] Step 240: Execute data proxy operations on the underlying database based on the database relational metamodel.

[0032] In specific application scenarios, the aggregation warehouse proxy implementation module can be pre-built. The aggregation warehouse proxy implementation module defines the general aggregation warehouse interface and methods, and obtains the mapping from the domain model to the database relational metamodel according to the domain model relational analysis module, and then automatically completes the proxy implementation of the aggregation warehouse to the underlying database operation according to the database relational metamodel. Data proxy operations can include data addition proxy operations, data modification proxy operations, data deletion proxy operations, and data query proxy operations.

[0033] The specific proxy implementation process is summarized as follows: 1) Get the aggregate root entity class associated with the warehouse interface; 2) Call the domain model relationship parsing module to obtain the database relationship metamodel (TableDef) corresponding to the aggregate root entity class; 3) Based on the warehouse method parameters, method semantics and the aggregated database relational metamodel, use the Mybatis-Flex framework to generate the corresponding underlying database SQL operations (and ensure that multiple SQL operations are in the same database transaction) and return the results.

[0034] In summary, according to the data processing method based on domain-driven design provided by the present invention, after obtaining the warehouse interface of the aggregate warehouse, the aggregate root entity and value object associated with the warehouse interface can be determined; then, the domain model can be aggregated and generated according to the definition specifications of the aggregate root entity and the value object; the domain model is further mapped to the database relational metamodel; finally, the data proxy operation for the underlying database is performed based on the database relational metamodel. The technical solution in this application can automatically complete the proxy implementation of the operation from the aggregate warehouse to the underlying database. For developers, they can directly call the corresponding aggregate warehouse interface, which greatly reduces the difficulty of developing the aggregate warehouse and improves the work efficiency of developers.

[0035] based on Figure 2 The embodiment shown is a refinement and extension of the above embodiment. In order to fully illustrate the specific implementation process of the method of this embodiment, this embodiment provides the following Figure 3 The specific method shown. Figure 3 based on Figure 2 As shown in 3, the method comprises the following steps: Step 310: Obtain the warehouse interface of the aggregate warehouse, and determine the aggregate root entity and value object associated with the warehouse interface.

[0036] For the embodiments of the present disclosure, the specific implementation process can refer to the relevant description in step 210 of the embodiment, which will not be repeated here.

[0037] Step 320: Aggregate and generate a domain model based on the definition specifications of the aggregate root entity and value object.

[0038] For the embodiment of the present disclosure, the domain model can be automatically aggregated and generated according to the definition specifications of the domain model about entities and value objects defined in the domain model definition specification module. The specific specification description is shown in Table 1: Table 1: Definition specifications of domain model entities and value objects

[0039]

[0040] Referring to this specification, the following is an example of a complete domain model definition for user aggregation: Java / / Entity class - User class User { / / Unique identifier String id; / / Common attributes - User name String name; / / Association ID - ID of the department to which the user belongs String deptId; / / Association ID collection - the role ID collection owned by the user List <string>roleIds; / / Associated value object - user detailed address Address address; / / Associated value object collection - list of office assets owned by the user List <userasset>userAssets; / / Omit getter and business methods... } / / Value object - user assets class UserAsset { / / Association ID - associated asset ID String assetId; / / General properties - asset quantity Integer count; / / Omit getter and business methods... } / / Value object - address class Address { / / General attributes - the province where the address is located String addressProv; / / General attributes - city where the address is located String addressCity; / / General attributes - address area String addressArea; / / General properties - detailed address description String addressDetail; / / Omit getter and business methods... } Step 330: Map the domain model to a database relational metamodel.

[0041] For the embodiment of the present disclosure, mapping the domain model to the database relational metamodel in step 330 may include the following steps: Step 330 - 1 , parse the domain model to obtain the domain object types contained in the domain model.

[0042] Step 330-2: Determine the preset mapping rule corresponding to the domain object type.

[0043] Different domain object types are configured with different preset mapping rules. Domain object types can be, for example, class names, attribute names, and the entire entity, unique identifier, associated identifier, associated identifier set, associated value object, associated value object set, common attributes in entity classes, and the entire value object, common attributes, and associated identifier in value objects. The specific mapping rules are as follows in Table 2: Table 2. Preset mapping rules for different domain object types

[0044]

[0045]

[0046]

[0047]

[0048] Step 330 - 3 : Map and transform each domain object based on preset mapping rules to obtain a database relational metamodel.

[0049] The database relational metamodel may include a table metamodel TableRef, an ID metamodel IdRef, a column metamodel ColumnRef, a foreign key metamodel ForeignKeyRef, a relation column metamodel RelationColumnRef, and a relation table metamodel RelationTableRef.

[0050] like Figure 4 As shown, each domain object on the left side of the figure is mapped and transformed based on the preset mapping rules to obtain the database relational metamodel on the right side of the figure. That is, mapping and transforming the unique identifier can obtain the ID metamodel; mapping and transforming the common attributes can obtain the column metamodel; mapping and transforming the association identifier can obtain the foreign key metamodel; mapping and transforming the association identifier set can obtain the association column metamodel; mapping and transforming the common attributes in the value object can obtain the column metamodel in the table metamodel; mapping and transforming the association identifier in the value object can obtain the foreign key metamodel in the table metamodel; mapping and transforming the common attributes in the value object set can obtain the column metamodel in the association table metamodel; mapping and transforming the association identifier in the value object set can obtain the foreign key metamodel in the table metamodel.

[0051] Step 340: Receive a data operation request for the underlying database, and generate data code according to the database relational metamodel in response to the data operation request.

[0052] Among them, data operation requests may include data addition requests, data modification requests, data deletion requests, and data query requests, etc.; database relational metamodels may include table metamodels TableRef, ID metamodels IdRef, column metamodels ColumnRef, foreign key metamodels ForeignKeyRef, associated column metamodels RelationColumnRef, associated table metamodels RelationTableRef, etc. In the following embodiment steps of the present application, the technical solution in the present application is described by taking the database relational metamodel including table metamodels, associated column metamodels, and associated table metamodels as an example, but it does not constitute a specific limitation.

[0053] In the domain model, an aggregate will correspond to multiple objects, and multiple objects will correspond to multiple database tables. When persisting the aggregate root (corresponding to a certain entity) (that is, calling the aggregate warehouse to persist the aggregate root), it is necessary to ensure that all related objects will be persisted together, and it is also necessary to ensure that multiple objects are queried together during query. This aggregate warehouse interface automatically proxy implements this mapping process (without the need for developers to manually configure and convert), and then the implementation steps of each warehouse method in Table 3 below will correspond to multiple steps, which fully considers the conversion of various parts of the domain model in DDD (entities, value objects, etc.) to database relationships.

[0054] Table 3. Warehouse method implementation steps

[0055]

[0056]

[0057] For the embodiment of the present disclosure, as a possible implementation method, when the data operation request is a data adding request, that is, the void insertAggr(T aggr) method, the specific implementation process is as follows: 1) Insert into the main table: parse the TableDef metamodel, obtain the tableName corresponding to the current entity, generate the column name to be inserted according to idDef, columnsDef, and foreignKeyDefs, and obtain the specific column value from the method parameter aggr (aggregate root to be inserted) through the column getter, generate and execute the main table insert statement, and take the user aggregation as an example to generate the insert statement as follows: SQL -- Format: insert into tableName(id, col1, ..., foreignKey1, ...) values(?, ...) INSERT INTO t_user(id, name, address_area, address_city, address_detail, address_prov, dept_id) VALUES ('u1', '张三', '浑南', '沈阳', '软件园', '辽宁', 'd1'); 2) Insert associated columns: Analyze the relationColumnDefs set in the TableDef meta-model. For each element in the relationColumnDefs set, sequentially obtain relationTableName, relationRefColumn, and mainRefColumn, and obtain the specific column values from the method parameter aggr (the aggregate root to be inserted) through the column's getter, generate and execute the batch insert statement for associated columns. Taking the user aggregate associated column roleIds as an example, the insert statement is generated as follows: SQL -- Format: insert into relationTableName(relationRelColumn,mainRefColumn) values (?,?) INSERT INTO t_user_role(role_id, user_id) VALUES ('r1', 'u1') INSERT INTO t_user_role(role_id, user_id) VALUES ('r2', 'u1') 3) Insert associated tables: Analyze the relationTableDefs set in the TableDef meta-model. For each element in the relationTableDefs set, sequentially obtain relationTableName, mainRefColumn, columnDefs, and foreignKeyDefs, and obtain the specific column values from the method parameter aggr (the aggregate root to be inserted) through the column's getter, generate and execute the batch insert statement for associated tables. Taking the user aggregate associated table userAssets as an example, the insert statement is generated as follows: SQL -- Format: insert into relationTableName(mainRefColumn, col1,..,foreignKey1,..) values (?,...?) INSERT INTO t_user_asset(user_id, count, asset_id) VALUES ('u1', 100, 'a1'); INSERT INTO t_user_asset(user_id, count, asset_id) VALUES ('u1', 200, 'a2'); Accordingly, the step 340 of generating data code according to the database relational metamodel in the embodiment may include the following steps: 340-1a. By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in turn.

[0058] 340 - 2a. Generate a first data inserting code for inserting data into the main table based on the main table data.

[0059] 340 - 3a. Generate a second data insert code based on the associated column data. When the second data insert code is executed, it is used to insert data into the associated column corresponding to the main table.

[0060] 340 - 4a. Generate a third data insertion code based on the associated table data. When the third data insertion code is executed, it is used to insert data into the associated table corresponding to the main table.

[0061] For the embodiment of the present disclosure, as another possible implementation, when the data operation request is a data modification request, that is, the void updateAggr(T aggr) method, the specific implementation process is as follows: 1) Modify the main table: parse the TableDef metamodel, obtain the tableName corresponding to the current entity, generate the column name to be inserted according to idDef, columnsDef, and foreignKeyDefs, and obtain the specific column value from the method parameter aggr (aggregate root to be inserted) through the column getter, generate and execute the main table modification statement, and take user aggregation as an example to generate the modification statement as follows: SQL -- Format: update tableName set col1=?, ..., foreignKey1=?, ... where id= ? UPDATE t_user SET name = 'Li Si' , address_area = 'Hunnan', address_city = 'Shenyang' , address_detail = 'National Games Village', address_prov = 'Liaoning', dept_id = 'd1' WHERE id = 'u1' 2) Modify the associated columns: parse the relationColumnDefs collection in the TableDef metamodel, and for each element in the relationColumnDefs collection, obtain relationTableName, relationRefColumn, and mainRefColumn in turn, and obtain the specific column value from the method parameter aggr (aggregate root to be inserted) through the column getter. First, generate and execute a delete statement to delete the original associated column records in relationTable, and then generate and execute a batch insert statement for the modified associated columns. Take the user aggregate associated column roleIds as an example to generate the delete and insert statements as follows: SQL -- Delete statement format: delete from relationTableName where mainRefColumn=? DELETE FROM t_user_role WHERE user_id = 'u1' -- Insert statement format: insert into relationTableName(relationRelColumn,mainRefColumn) values ​​(?, ?) INSERT INTO t_user_role(role_id, user_id) VALUES ('r1', 'u1') INSERT INTO t_user_role(role_id, user_id) VALUES ('r2', 'u1') 3) Modify the association table: Parse the relationTableDefs collection in the TableDef metamodel, and for each element in the relationTableDefs collection, get relationTableName, mainRefColumn, columnDefs, and foreignKeyDefs in turn, and get the specific column value from the method parameter aggr (aggregate root to be inserted) through the column getter. First, generate and execute a delete statement to delete the original associated table records in relationTable, and then generate and execute a batch insert statement for the modified associated table. Take the user aggregate associated table userAssets as an example to generate the delete and insert statements as follows: SQL -- Delete statement format: delete from relationTableName where mainRefColumn=? DELETE FROM t_user_role WHERE user_id = 'u1' -- Insert statement format: insert into relationTableName(mainRefColumn, col1,..,foreignKey1,..) values ​​(?,...?) INSERT INTO t_user_asset(user_id, count, asset_id) VALUES ('u1', 100, 'a1'); INSERT INTO t_user_asset(user_id, count, asset_id) VALUES ('u1', 200, 'a2'); Accordingly, the step 340 of generating data code according to the database relational metamodel in the embodiment may include the following steps: 340-1b. By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in turn.

[0062] 340 - 2b. Generate a first data modification code for modifying the main table based on the main table data.

[0063] 340-3b. Delete the first historical modification data code corresponding to the associated column in the main table, generate a second modification data code based on the associated column data, and the second modification data code is used to modify the associated column when executed.

[0064] 340-4b. Delete the second historical modification data code corresponding to the associated table in the main table, and generate a third modification data code based on the associated table data. The third modification data code is used to modify the associated table when executed.

[0065] For the embodiment of the present disclosure, as another possible implementation, when the data operation request is a data deletion request, that is, the void deleteAggrById(Serializable id) and void deleteAggrByIds(Collectionids) methods, the specific implementation process is as follows, taking deleteByAggrById as an example: 1) Delete the associated column: parse the relationColumnDefs collection in the TableDef metamodel, and obtain the relationTableName and mainRefColumn for each element in the relationColumnDefs collection. The value corresponding to the mainRefColumn column is the value of the parameter id. Generate and execute a delete statement to delete the associated column records in the relationTable according to the mainRelColumn. Take the user aggregate associated column roleIds as an example to generate the delete statement as follows: SQL -- Format: delete from relationTableName where mainRefColumn=? DELETE FROM t_user_role WHERE user_id = 'u1' 2) Delete the associated table: Parse the relationTableDefs collection in the TableDef metamodel, and for each element in the relationTableDefs collection, obtain relationTableName and mainRefColumn in turn. The value corresponding to the mainRefColumn column is the value of the parameter id. Generate and execute a delete statement to delete the records of the associated table in relationTable according to mainRelColumn. Take the user aggregation associated table userAssets as an example to generate the insert statement as follows: SQL -- Format: delete from relationTableName where mainRefColumn=? DELETE FROM t_user_role WHERE user_id = 'u1' 3) Delete the main table: parse the TableDef metamodel, obtain the tableName corresponding to the current entity, obtain the id column name according to idDef, the id column value is the value of the parameter id, generate and execute a statement to delete the main table record according to the id, and take user aggregation as an example to generate the deletion statement as follows: SQL -- Format: delete from tableName where id = ? DELETE FROM t_user_role WHERE user_id = 'u1' The implementation process of the batch deletion method deleteByAggrByIds is basically the same as that of deleteAggById. The only difference is that deleteByAggrByIds needs to change the deletion condition from equality = to inclusion in, that is, change from where user_id ={id} to user_id in {ids}.

[0066] Accordingly, the step 340 of generating data code according to the database relational metamodel in the embodiment may include the following steps: 340-1c. By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in turn.

[0067] 340-2c. Generate a first data deletion code for deleting the main table based on the associated column data.

[0068] 340-3c. Generate a second data deletion code based on the associated column data. When the second data deletion code is executed, it is used to delete the associated column corresponding to the main table.

[0069] 340-4c. Generate a third data deletion code based on the associated table data. When the third data deletion code is executed, it is used to delete the associated table corresponding to the main table.

[0070] For the embodiment of the present disclosure, as another possible implementation, when the data operation request is a data query request, that is, T findAggrById(Serializable id), T findAggrOne(QueryWrapperqueryWrapper), List <t>findAggrList ( QueryWrapper queryWrapper ) 、Page <t>findAggrPage(Number pageNumber, Number pageSize, QueryWrapper queryWrapper) method. The first four methods are basically similar in implementation and are described together. The last findAggrPage method is special and is described separately.

[0071] First, use the T findAggrOne(QueryWrapper queryWrapper) method. The specific implementation process is as follows: 1) Reuse query conditions: that is, reuse the QueryWrapper parameter in the parameter (the parameter is provided by the MyBatis-Flex framework). The QueryWrapper parameter can be used to construct complex SQL where conditions. The specific construction is defined by the user. The present invention additionally provides a Query tool class, which can be used to automatically obtain the table name and column name corresponding to the entity and value object attributes. The specific usage examples of QueryWrapper and Query tool class are as follows: Java QueryWrapper queryWrapper = QueryWrapper.create() .eq(Query.column(User::getId), "u1") .eq(Query.column(User::getDeptId), "d1") .eq(Query.column(Address::getProv), "Liaoning") / / The associated column is adjusted to the form of the main table ID matching subquery .in(Query.column(User::getId), Query.relationQuery(User::getRoleIds,QueryWrapper::eq, "r1")) / / The attributes in the associated table are adjusted to match the subquery in the main table ID .in(Query.column(User::getId), Query.relationQuery(UserAsset::getAssetId, QueryWrapper::eq, "a1")); It should be noted that in the aggregate root entity, if the attributes in the associated columns and associated tables are used as filtering conditions, directly matching the conditions through columns will result in incomplete data in the associated columns and associated tables. The present invention can use the Query tool to uniformly adjust them to the form of main table ID matching subquery, thereby ensuring that the associated columns and associated tables in the aggregate root are returned as a whole. For example, the roleIds of user u1 include [r1, r2]. At this time, if you want to query users whose roleId is equal to r1, you should return {id: u1, roleIds: [r1, r2]} instead of {id: u1, roleIds: [r1]}.

[0072] 2) Generate query columns: parse the TableDef metamodel, generate the main table column name to be queried based on idDef, columnsDef, and foreignKeyDefs, generate the associated column name to be queried based on relationColumnRefs, generate the column name (ordinary column, foreign key) of the associated table to be queried based on relationTableDefs, and set the column name to be queried through the select method of QueryWrapper.

[0073] 3) Generate the query main table: parse the TableDef metamodel, obtain the tableName corresponding to the current entity, and set the table name to the current tableName through the from method of QueryWrapper.

[0074] 4) Generate query connection table: parse TableDef metamodel, generate (multiple) association table names and connection conditions to be connected according to relationColumnRefs, generate (multiple) association table names and connection conditions to be connected according to relationTableDefs, and set the table names and connection conditions to be connected through the leftJoin method of QueryWrapper.

[0075] 5) Generate and execute SQL: Call the Mybatis-Flex BaseMapper underlying method BaseMapper.selectOneByQuery(queryWrapper) to complete the execution of the query SQL statement and the mapping of the query results.

[0076] It should be noted that T findAggrById(Serializable id), T findAggrOne(QueryWrapper queryWrapper), List <t>The implementation process of findAggrList(QueryWrapper queryWrapper) is similar. FindAggrById is only adjusted to query the aggregated QueryWrapper by ID in the first step, and findAggrList is only adjusted to call BaseMapper.selectListByQuery(queryWrapper) method in the fifth step.

[0077] Taking querying user aggregation as an example, the query statement generated is as follows: SQL -- 2) Generate query columns SELECT t_user.id, t_user.name, t_user.address_area, t_user.address_city, t_user.address_detail, t_user.address_prov, t_user.dept_id, t_user_role.role_id AS role_ids, t_user_asset.asset_id, t_user_asset.count -- 2) Generate query master table FROM t_user -- 3) Generate query join table - associated columns LEFT JOIN t_user_role ON t_user.id = t_user_role.user_id -- 3) Generate query connection table - association table LEFT JOIN t_user_asset ON t_user.id = t_user_asset.user_id -- 1) Reuse query conditions WHERE t_user.id = 'u1' AND t_user.dept_id = 'd1' AND t_user.address_prov = 'Liaoning' -- The associated columns are adjusted to match the subquery of the main table ID AND t_user.id IN ( SELECT user_id FROM t_user_role WHERE role_id = 'r1' ) -- The attributes in the associated table are adjusted to match the subquery of the main table ID AND t_user.id IN ( SELECT user_id FROM t_user_asset WHERE asset_id = 'a1' ) Accordingly, the step 340 of generating data code according to the database relational metamodel in the embodiment may include the following steps: 340-1d. By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in turn.

[0078] 340-2d. Call the query builder to determine the column name to be queried and the main table name to be queried in the main table data based on the query condition, and determine the connection table name to be queried and the connection condition in the associated column data and the associated table data based on the query condition.

[0079] 340-3d. Generate query data code based on the name of the column to be queried, the name of the main table to be queried, the name of the connection table to be queried and the connection conditions.

[0080] In specific application scenarios, a paging query method is also provided, that is, about Page <t>findAggrPage(Number pageNumber, Number pageSize, QueryWrapper queryWrapper) method, which needs to be implemented through three queries: 1) Query the total number of main table IDs: First reuse the query conditions, then set to query only the main table, and finally call the BaseMapper.selectCountByQuery method (the query column only contains count(*)). The returned result is the total number of main table IDs that meet the query conditions. Taking the query of the user aggregate paging list as an example, the statement to generate the query total is as follows: SQL -- The query column only contains count(*) SELECT COUNT(*) -- Query only the main table FROM t_user -- Reuse query conditions WHERE t_user.id = 'u1' AND t_user.dept_id = 'd1' AND t_user.address_prov = 'Liaoning' AND t_user.id IN ( SELECT user_id FROM t_user_role WHERE role_id = 'r1' ) AND t_user.id IN ( SELECT user_id FROM t_user_asset WHERE asset_id = 'a1' ) 2) Query the ID set of the main table of the current page: First reuse the query conditions, then set the query column to only include the main table ID column, then set it to query only the main table, and finally call the BaseMapper.paginateAs(pageNumber, pageSize, total, selectEntityIdsOfPage, Object.class) method (compatible with the paging syntax of different databases). The result returned is the ID set of the main table of the current page that meets the query conditions. Taking the query of the user aggregate paging list as an example, the SQL statement (MySQL syntax) for querying the ID set of the main table of the current page is generated as follows: SQL -- The query column contains only the primary table ID SELECT t_user.id -- Query only the main table FROM t_user -- Reuse query conditions WHERE t_user.id = 'u1' AND t_user.dept_id = 'd1' AND t_user.address_prov = 'Liaoning' AND t_user.id IN ( SELECT user_id FROM t_user_role WHERE role_id = 'r1' ) AND t_user.id IN ( SELECT user_id FROM t_user_asset WHERE asset_id = 'a1' ) -- Paging conditions (MySQL syntax) LIMIT 0, 10 3) Query the aggregate data list based on the main table ID: First set the complete query column, then set the query main table and query connection table, and then rewrite the query condition QueryWrapper to only contain the only query condition: main table ID in {main table ID collection of the current page}, and finally call the BaseMapper.selectListByQuery(QueryWrapper) method to return the result, which is the aggregate root list of the current page that meets the query condition. Taking the query of the user aggregate paging list as an example, the SQL statement to query the aggregate root list of the current page is as follows: SQL -- Generate query columns SELECT t_user.id, t_user.name, t_user.address_area, t_user.address_city, t_user.address_detail, t_user.address_prov, t_user.dept_id, t_user_role.role_id AS role_ids, t_user_asset.asset_id, t_user_asset.count -- Generate query master table FROM t_user -- Generate query join table - associated columns LEFT JOIN t_user_role ON t_user.id = t_user_role.user_id -- Generate query connection table - association table LEFT JOIN t_user_asset ON t_user.id = t_user_asset.user_id -- Contains only unique query conditions: main table ID in {main table ID set of previous page} WHERE t_user.id IN ( 'u1' ) 4) Assemble query results: The paginated results include the total number and the current page data list, where the total number corresponds to the total number in step 1, and the current page data list corresponds to the aggregate root list in step 3.

[0081] Step 350: Execute data proxy operations on the underlying database based on the data code.

[0082] For the embodiment of the present disclosure, as a possible implementation, when the data operation request is a data adding request, the data proxy operation for the underlying database based on the data code in step 350 of the embodiment may include the following steps: Step 350-1a, by sequentially executing the first data insertion code, the second data insertion code and the third data insertion code, the data adding proxy operation for the underlying database is completed.

[0083] For the embodiment of the present disclosure, as another possible implementation, when the data operation request is a data modification request, executing the data proxy operation on the underlying database based on the data code in step 350 of the embodiment may include the following steps: Step 350-1b: Complete the data modification proxy operation on the underlying database by sequentially executing the first data modification code, the second data modification code, and the third data modification code.

[0084] For the embodiment of the present disclosure, as another possible implementation, when the data operation request is a data deletion request, executing the data proxy operation on the underlying database based on the data code in step 350 of the embodiment may include the following steps: Step 350-1c, by sequentially executing the first data deletion code, the second data deletion code, and the third data deletion code, the data deletion proxy operation on the underlying database is completed.

[0085] For the embodiment of the present disclosure, as another possible implementation, when the data operation request is a data query request, the data proxy operation for the underlying database based on the data code in step 350 of the embodiment may include the following steps: Step 350-1d: Complete the data query proxy operation on the underlying database by executing the query data code.

[0086] In summary, the technical solution in this application does not need to rely on cumbersome ORM annotations for the domain model, which is specifically embodied in that the domain model definition specification module gives the definition specifications of entities and value objects in DDD. This specification conforms to the conventional domain-driven design and development habits. Developers do not need to understand the concept of complex ORM and do not need to rely on cumbersome annotations, which reduces the difficulty of developers to get started, allowing developers to focus more on the design of the domain model without paying too much attention to the conversion between the underlying domain model and the database model. In addition, the domain model relationship parsing module parses the entities and value objects defined according to the requirements of the domain model definition specification module, completes the automatic mapping of the domain model to the database relational metamodel, and the aggregation warehouse proxy implementation module predefines the general aggregation warehouse interface and method, and obtains the mapping of the domain model to the database relational metamodel according to the domain model relationship parsing module, and then automatically completes the proxy implementation (addition, modification, deletion, query) of the aggregation warehouse to the underlying database operation according to the database relational metamodel. For developers, it is sufficient to directly call the corresponding aggregation warehouse interface, and the underlying database operation is automatically parsed, mapped, and executed by the present invention, which greatly reduces the development difficulty of the aggregation warehouse and improves the work efficiency of developers.

[0087] Based on the above Figure 2 , Figure 3 A detailed description of the data processing method based on domain-driven design is provided, such as Figure 5 As shown, Figure 5 is a structural block diagram of a data processing device based on domain-driven design according to an exemplary embodiment. Figure 5 As shown, the device comprises: A determination module 51 may be used to obtain a warehouse interface of an aggregate warehouse and determine an aggregate root entity and a value object associated with the warehouse interface; A generation module 52, which can be used to aggregate and generate a domain model according to the definition specifications of the aggregate root entity and the value object; A mapping module 53, which can be used to map the domain model into a database relational metamodel, where the database relational metamodel represents the specific representation and composition of the domain model in the underlying database; The proxy module 54 may be used to perform data proxy operations on the underlying database based on the database relational metamodel.

[0088] In some embodiments of the present application, the mapping module 53 can be specifically used to parse the domain model to obtain the domain object type contained in the domain model; determine the preset mapping rules corresponding to the domain object type, wherein different domain object types are configured with different preset mapping rules; and perform mapping transformation on each domain object based on the preset mapping rules to obtain a database relational metamodel.

[0089] In some embodiments of the present application, the proxy module 54 can be specifically used to receive data operation requests for the underlying database; generate data codes according to the database relational metamodel in response to the data operation requests; and perform data proxy operations on the underlying database based on the data codes.

[0090] In some embodiments of the present application, a data operation request includes a data addition request, and a database relational metamodel includes a table metamodel, an associated column metamodel, and an associated table metamodel; when generating data code according to the database relational metamodel, the proxy module 54 can be specifically used to parse the table metamodel, the associated column metamodel, and the associated table metamodel to obtain the main table data, the associated column data, and the associated table data in the underlying database in sequence; generate a first insert data code for inserting data into the main table based on the main table data; generate a second insert data code based on the associated column data, and the second insert data code is used to insert data into the associated column corresponding to the main table when executed; generate a third insert data code based on the associated table data, and the third insert data code is used to insert data into the associated table corresponding to the main table when executed.

[0091] Correspondingly, when executing the data proxy operation on the underlying database based on the data code, the proxy module 54 can be specifically used to complete the data addition proxy operation on the underlying database by sequentially executing the first insert data code, the second insert data code and the third insert data code.

[0092] In some embodiments of the present application, a data operation request includes a data modification request, and a database relational metamodel includes a table metamodel, an associated column metamodel, and an associated table metamodel; when generating data code according to the database relational metamodel, the proxy module 54 can be specifically used to parse the table metamodel, the associated column metamodel, and the associated table metamodel to obtain the main table data, the associated column data, and the associated table data in the underlying database in turn; generate a first modification data code for modifying the main table based on the main table data; delete the first historical modification data code corresponding to the associated column in the main table, generate a second modification data code based on the associated column data, and the second modification data code is used to modify the associated column when executed; delete the second historical modification data code corresponding to the associated table in the main table, generate a third modification data code based on the associated table data, and the third modification data code is used to modify the associated table when executed.

[0093] Correspondingly, when executing data proxy operations on the underlying database based on the data code, the proxy module 54 can be specifically used to complete the data modification proxy operations on the underlying database by sequentially executing the first data modification code, the second data modification code and the third data modification code.

[0094] In some embodiments of the present application, the data operation request includes a data deletion request, and the database relational metamodel includes a table metamodel, an associated column metamodel, and an associated table metamodel; when generating data code according to the database relational metamodel, the proxy module 54 can be specifically used to parse the table metamodel, the associated column metamodel, and the associated table metamodel to obtain the main table data, the associated column data, and the associated table data in the underlying database in sequence; generate a first deletion data code for deleting the main table based on the associated column data; generate a second deletion data code based on the associated column data, and the second deletion data code is used to delete the associated column corresponding to the main table when executed; generate a third deletion data code based on the associated table data, and the third deletion data code is used to delete the associated table corresponding to the main table when executed.

[0095] Correspondingly, when executing the data proxy operation on the underlying database based on the data code, the proxy module 54 can be specifically used to complete the data deletion proxy operation on the underlying database by sequentially executing the first data deletion code, the second data deletion code and the third data deletion code.

[0096] In some embodiments of the present application, the data operation request includes a data query request, and the database relational metamodel includes a table metamodel, an associated column metamodel, and an associated table metamodel; when generating data code according to the database relational metamodel, the proxy module 54 can be specifically used to parse the table metamodel, the associated column metamodel, and the associated table metamodel to obtain the main table data, the associated column data, and the associated table data in the underlying database in sequence; call the query builder to determine the column name to be queried and the main table name to be queried in the main table data based on the query conditions, and determine the connection table name to be queried and the connection conditions in the associated column data and the associated table data based on the query conditions; generate query data code based on the column name to be queried, the main table name to be queried, the connection table name to be queried, and the connection conditions.

[0097] Correspondingly, when a data proxy operation is performed on the underlying database based on the data code, the proxy module 54 can be specifically used to complete the data query proxy operation on the underlying database by executing the query data code.

[0098] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0099] In the embodiment of the present application, after obtaining the warehouse interface of the aggregate warehouse, the aggregate root entity and value object associated with the warehouse interface can be determined; then, the domain model can be aggregated and generated according to the definition specifications of the aggregate root entity and value object; the domain model can be further mapped to the database relational metamodel; finally, the data proxy operation for the underlying database is performed based on the database relational metamodel. The technical solution in the present application can automatically complete the proxy implementation of the operation from the aggregate warehouse to the underlying database. For developers, they can directly call the corresponding aggregate warehouse interface, which greatly reduces the difficulty of developing the aggregate warehouse and improves the work efficiency of developers.

[0100] In the above, the data processing device based on domain-driven design in the embodiment of the present invention is described from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that the functional module can be implemented in hardware form, can be implemented by instructions in software form, and can also be implemented by a combination of hardware and software modules. Specifically, the steps of the data processing method embodiment based on domain-driven design in the embodiment of the present invention can be completed by the hardware integrated logic circuit and / or software instructions in the processor, and the steps of the data processing method based on domain-driven design applied in conjunction with the embodiment of the present invention can be directly embodied as a hardware decoding processor to execute, or a combination of hardware and software modules in the decoding processor to execute. Optionally, the software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory, and completes the steps in the above-mentioned data processing method embodiment based on domain-driven design in conjunction with its hardware.

[0101] Figure 6 is a schematic block diagram of an electronic device 600 according to an embodiment of the present invention.

[0102] like Figure 6 As shown, the electronic device 600 may include: The memory 610 and the processor 620, the memory 610 is used to store the computer program and transmit the program code to the processor 620. In other words, the processor 620 can call and run the computer program from the memory 610 to implement the method in the embodiment of the present invention.

[0103] For example, the processor 620 may be configured to execute the above method embodiments according to instructions in the computer program.

[0104] In some embodiments of the present invention, the processor 620 may include but is not limited to: General-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0105] In some embodiments of the present invention, the memory 610 includes but is not limited to: Volatile memory and / or non-volatile memory. Among them, the non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct memory bus random access memory (Direct Rambus RAM, DR RAM).

[0106] In some embodiments of the present invention, the computer program may be divided into one or more modules, which are stored in the memory 610 and executed by the processor 620 to complete the method provided by the present invention. The one or more modules may be a series of computer program instruction segments capable of completing specific functions, and the instruction segments are used to describe the execution process of the computer program in the controller.

[0107] like Figure 6 As shown, the electronic device 600 may further include: The transceiver 630 may be connected to the processor 620 or the memory 610 .

[0108] The processor 620 may control the transceiver 630 to communicate with other devices, specifically, to send data to other devices or receive data sent by other devices. The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include an antenna, and the number of antennas may be one or more.

[0109] It should be understood that the various components in the electronic device are connected via a bus system, wherein the bus system includes not only a data bus but also a power bus, a control bus and a status signal bus.

[0110] The present invention also provides a computer storage medium having a computer program stored thereon, which, when executed by a computer, enables the computer to perform the method of the above method embodiment. In other words, an embodiment of the present invention also provides a computer program product containing instructions, which, when executed by a computer, enables the computer to perform the method of the above method embodiment.

[0111] When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (Digital Video Disc, DVD)), or a semiconductor medium (e.g., a solid-state drive (SSD)), etc.

[0112] Those skilled in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments applied herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0113] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the module is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0114] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. For example, each functional module in each embodiment of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0115] The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in this application, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.< / t> < / t> < / t> < / t> < / userasset> < / string>

Claims

1. A data processing method based on domain-driven design, characterized in that: include: Obtaining a repository interface of an aggregate repository, and determining aggregate root entities and value objects associated with the repository interface; Aggregate and generate a domain model according to the definition specifications of the aggregate root entity and the value object; Mapping the domain model to a database relational metamodel, wherein the database relational metamodel represents a specific representation and composition of the domain model in an underlying database; A data proxy operation is performed on the underlying database based on the database relational metamodel.

2. The method according to claim 1, characterized in that Mapping the domain model to a database relational metamodel includes: Parsing the domain model to obtain the domain object types contained in the domain model; Determine a preset mapping rule corresponding to the domain object type, wherein different domain object types are configured with different preset mapping rules; Mapping conversion is performed on each of the domain objects based on the preset mapping rules to obtain a database relational metamodel.

3. The method according to claim 1, characterized in that: The performing of the data proxy operation on the underlying database based on the database relational metamodel includes: Receiving a data operation request for the underlying database; In response to the data operation request, generating data code according to the database relational metamodel; Based on the data code, a data proxy operation is performed on the underlying database.

4. The method according to claim 3, characterized in that The data operation request includes a data adding request, and the database relational metamodel includes a table metamodel, an associated column metamodel and an associated table metamodel; The step of generating data code according to the database relational metamodel comprises: By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in sequence; Generate a first data inserting code for inserting data into the main table based on the main table data; generating a second data insertion code based on the associated column data, wherein the second data insertion code is used to insert data into the associated column corresponding to the main table when executed; generating a third data insertion code based on the association table data, wherein the third data insertion code is used to insert data into the association table corresponding to the main table when executed; The performing of the data proxy operation on the underlying database based on the data code includes: By sequentially executing the first data insertion code, the second data insertion code, and the third data insertion code, the data adding proxy operation on the underlying database is completed.

5. The method according to claim 3, characterized in that: The data operation request includes a data modification request, and the database relational metamodel includes a table metamodel, an associated column metamodel, and an associated table metamodel; The step of generating data code according to the database relational metamodel comprises: By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in sequence; Generate a first modification data code for modifying the main table based on the main table data; Deleting a first historical modification data code corresponding to the associated column in the main table, and generating a second modification data code based on the associated column data, wherein the second modification data code is used to modify the associated column when executed; Deleting the second historical modification data code corresponding to the association table in the main table, and generating a third modification data code based on the association table data, wherein the third modification data code is used to modify the association table when executed; The performing of the data proxy operation on the underlying database based on the data code includes: The data modification proxy operation on the underlying database is completed by sequentially executing the first data modification code, the second data modification code and the third data modification code.

6. The method according to claim 3, characterized in that The data operation request includes a data deletion request, and the database relational metamodel includes a table metamodel, an associated column metamodel, and an associated table metamodel; The step of generating data code according to the database relational metamodel comprises: By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in sequence; Generate a first deletion data code for deleting the main table based on the associated column data; generating a second deletion data code based on the associated column data, wherein the second deletion data code is used to delete the associated column corresponding to the main table when executed; generating a third deletion data code based on the association table data, wherein the third deletion data code is used to delete the association table corresponding to the main table when executed; The performing of the data proxy operation on the underlying database based on the data code includes: The data deletion proxy operation on the underlying database is completed by sequentially executing the first data deletion code, the second data deletion code and the third data deletion code.

7. The method according to claim 3, characterized in that The data operation request includes a data query request, and the database relational metamodel includes a table metamodel, an associated column metamodel, and an associated table metamodel; The step of generating data code according to the database relational metamodel comprises: By parsing the table metamodel, the associated column metamodel and the associated table metamodel, the main table data, the associated column data and the associated table data in the underlying database are obtained in sequence; Calling a query builder, determining a column name to be queried and a main table name to be queried in the main table data based on a query condition, and determining a connection table name to be queried and a connection condition in the associated column data and the associated table data based on the query condition; Generate a query data code based on the column name to be queried, the main table name to be queried, the connection table name to be queried and the connection condition; The performing of the data proxy operation on the underlying database based on the data code includes: By executing the data query code, a data query proxy operation for the underlying database is completed.

8. A data processing device based on domain-driven design, characterized in that: include: A determination module, used to obtain a warehouse interface of an aggregate warehouse, and to determine an aggregate root entity and a value object associated with the warehouse interface; A generation module, used to aggregate and generate a domain model according to the definition specifications of the aggregate root entity and the value object; A mapping module, used to map the domain model into a database relational metamodel, wherein the database relational metamodel represents the specific representation and composition of the domain model in the underlying database; The proxy module is used to perform data proxy operations on the underlying database based on the database relational metamodel.

9. An electronic device, characterized in that: include: A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein the computer program enables a computer to execute the method according to any one of claims 1 to 7.

Images