Domain drive design architecture, data processing method and device and storage medium

Abstract

The embodiment of the invention provides a domain-driven design architecture, a data processing method, equipment and a storage medium, the domain-driven design architecture comprises an interface layer, a logic layer and a domain layer, the domain layer comprises a domain model divided based on at least one of functions, data and business domains, and the domain model is used for packaging and realizing business logic; the interface layer is used for receiving a user request, converting the user request into a command object and calling the logic layer to process the command object; the user request has a corresponding service target; the logic layer is used for calling the domain layer to arrange the business process according to the command object and triggering a transaction for realizing the business process; the domain layer is used for calling a target domain model from the domain models according to the business process so as to realize a business target corresponding to the user request; wherein the business process is driven by business logic in the target domain model. According to the embodiment of the invention, the problem that a domain model and an actual service in a traditional architecture are disjointed can be solved.

Description

Technical Field

[0001] The present application relates to the field of software engineering technology, and in particular to a domain-driven design architecture, a data processing method, an electronic device, and a storage medium. Background Art

[0002] Currently, the three-tier MVC (Model View Controller) architecture, a software architecture pattern, is a common architectural pattern in software design. Combining object-oriented design, interface-oriented programming, and functional programming, these patterns can meet development needs to a certain extent. However, in complex business scenarios, the MVC architecture exhibits significant shortcomings in adapting to frequently changing requirements. While software architecture based on DDD (Domain-Driven Design) can effectively meet the needs of complex businesses and be applied to complex business systems, its reliance on manual experience to define business boundaries lacks unified standards, which can easily lead to blurred business boundaries or over-engineering, resulting in a disconnect between domain models and actual business operations. Summary of the Invention

[0003] The embodiments of the present application provide a domain-driven design architecture to solve the problem of disconnection between domain models and actual business in traditional architectures.

[0004] Accordingly, the embodiments of the present application also provide a data processing method, an electronic device, and a storage medium to ensure the implementation and application of the above method.

[0005] To address the above issues, embodiments of the present application disclose a domain-driven design architecture, comprising an interface layer, a logic layer, and a domain layer. The domain layer comprises a domain model divided based on at least one of function, data, and business domains, and the domain model is used to encapsulate and implement business logic.

[0006] The interface layer is used to receive user requests, convert the user requests into command objects, and call the logic layer to process the command objects; the user requests have corresponding business objectives;

[0007] The logic layer is used to call the domain layer to orchestrate the business process according to the command object and trigger the transaction for implementing the business process;

[0008] The domain layer is used to call the target domain model from the domain model according to the business process to achieve the business goal corresponding to the user request; wherein the business process is driven by the business logic in the target domain model.

[0009] Optionally, the interface layer includes: an input data verification module, a protocol adaptation module, and an output data encapsulation module; the interface layer is used to receive user requests and convert the user requests into command objects, including:

[0010] The input data verification module is used to perform data verification on the user request; the user request is sent by an external system or an internal client;

[0011] The protocol adaptation module is used to provide the communication protocol corresponding to the external system or the internal client;

[0012] The output data encapsulation module is used to encapsulate the user request after data verification according to the communication protocol to obtain the command object.

[0013] Optionally, the logic layer includes: a decomposition module, an assembly module, and an orchestration module; the logic layer is used to call the domain layer to orchestrate the business process according to the command object, including:

[0014] The decomposition module is used to decompose the command object to obtain multiple sub-operations;

[0015] The assembling module is used to determine the operation sequence of multiple sub-operations and assemble the multiple sub-operations into business steps according to the operation sequence;

[0016] The orchestration module is used to call the domain layer to orchestrate the business process according to the business steps; the business process is executed by multiple sub-operations in the operation sequence.

[0017] Optionally, the domain layer includes a business domain model, a domain division module, a model selection module, and a logic execution module. The domain model includes domain objects. The domain layer is used to call a target domain model from the domain model according to the business process to achieve the business goal corresponding to the user request, including:

[0018] The domain division module is used to divide the business domain model into multiple domain models according to business functions; and / or, divide the business domain model into multiple domain models according to the type, source and storage method of business data; and / or, divide the business domain model into multiple domain models according to business domains;

[0019] The model selection module is used to match the target domain model from the domain model according to the business process;

[0020] The logic execution module is used to execute the business logic in the target domain model through the domain objects in the target domain model to achieve the business goal corresponding to the user request.

[0021] Optionally, the domain model includes domain objects, and the domain layer further includes a lazy loading module, a cache module, and an object reuse module;

[0022] The lazy loading module is used to adopt a lazy loading mechanism for a first domain object that does not need to be loaded immediately among the domain objects, and load the data corresponding to the first domain object only when the first domain object is accessed;

[0023] The cache module is used to cache the second domain object whose access frequency is higher than the preset frequency threshold among the domain objects, so that the data corresponding to the second domain object is directly used when the second domain object is accessed;

[0024] The object reuse module is used to reuse the third domain object whose creation cost is higher than a preset cost threshold in the domain objects and to share the fourth domain object that is not allowed to be modified in the domain objects.

[0025] Optionally, the domain model includes domain objects, the domain objects include domain services that provide operations and domain events that are used to represent business significance within the domain model, the domain services are used to process the domain events, the domain events include direct domain events directly associated with the domain services and indirect domain events indirectly associated with the domain services, and the domain layer further includes an event binding module and an event processing module;

[0026] The event binding module is used to bind the domain event to the target phase of the transaction when the domain event is published; the target phase is used to represent the time point when the domain event is triggered;

[0027] The event processing module is used to limit the domain service to process the direct domain event.

[0028] Optionally, the architecture further includes a base layer, and the base layer further includes: a batch operation module and a database;

[0029] The base layer is used to provide an access interface to the database, so that the target domain model in the domain layer can access the database when running;

[0030] The base layer is also used to implement the transaction;

[0031] The batch operation module is used to merge the read and write operations corresponding to multiple databases into batch tasks.

[0032] The present application also discloses a data processing method, which is applied to the above-mentioned domain-driven design architecture. The architecture includes: an interface layer, a logic layer, and a domain layer. The domain layer includes a domain model divided based on at least one of function, data, and business domains. The domain model is used to encapsulate and implement business logic. The method includes:

[0033] receiving a user request through the interface layer, converting the user request into a command object, and calling the logic layer to process the command object; the user request has a corresponding business goal;

[0034] Calling the domain layer to orchestrate a business process according to the command object through the logic layer, and triggering a transaction for implementing the business process;

[0035] The target domain model is called from the domain model through the domain layer according to the business process to achieve the business goal corresponding to the user request; wherein the business process is driven by the business logic in the target domain model.

[0036] Optionally, the interface layer includes: an input data verification module, a protocol adaptation module, and an output data encapsulation module; receiving a user request through the interface layer and converting the user request into a command object includes:

[0037] Performing data verification on the user request through the input data verification module; the user request is sent by an external system or an internal client;

[0038] Providing the communication protocol corresponding to the external system or the internal client through the protocol adaptation module;

[0039] The output data encapsulation module encapsulates the user request after data verification according to the communication protocol to obtain the command object.

[0040] Optionally, the logic layer includes: a decomposition module, an assembly module, and an orchestration module; and the orchestration of the business process by calling the domain layer according to the command object through the logic layer includes:

[0041] Decomposing the command object by the decomposition module to obtain multiple sub-operations;

[0042] Determining the operation sequence of multiple sub-operations through the assembly module, and assembling the multiple sub-operations into business steps according to the operation sequence;

[0043] The domain layer is called by the orchestration module to orchestrate the business process according to the business steps; the business process is executed by multiple sub-operations in the operation sequence.

[0044] Optionally, the domain layer includes a business domain model, a domain division module, a model selection module, and a logic execution module. The domain model includes domain objects. Calling a target domain model from the domain model according to the business process through the domain layer to achieve the business goal corresponding to the user request includes:

[0045] The business domain model is divided into multiple domain models according to business functions by the domain division module; and / or, the business domain model is divided into multiple domain models according to the type, source and storage method of business data; and / or, the business domain model is divided into multiple domain models according to business domains;

[0046] Matching the target domain model from the domain model according to the business process through the model selection module;

[0047] The business logic in the target domain model is executed by the logic execution module through the domain objects in the target domain model to achieve the business goal corresponding to the user request.

[0048] Optionally, the domain model includes domain objects, and the domain layer further includes a lazy loading module, a cache module, and an object reuse module;

[0049] A lazy loading mechanism is adopted for a first domain object that does not need to be loaded immediately among the domain objects by the lazy loading module, and data corresponding to the first domain object is loaded only when the first domain object is accessed;

[0050] caching a second domain object in the domain objects whose access frequency is higher than a preset frequency threshold by the cache module, so that the data corresponding to the second domain object is directly used when the second domain object is accessed;

[0051] The object reuse module reuses the third domain object whose creation cost is higher than a preset cost threshold in the domain objects and shares the fourth domain object that is not allowed to be modified in the domain objects.

[0052] Optionally, the domain model includes domain objects, the domain objects include domain services that provide operations and domain events that are used to represent business significance within the domain model, the domain services are used to process the domain events, the domain events include direct domain events directly associated with the domain services and indirect domain events indirectly associated with the domain services, and the domain layer further includes an event binding module and an event processing module;

[0053] When the domain event is published, the domain event is bound to the target phase of the transaction through the event binding module; the target phase is used to represent the time point when the domain event is triggered;

[0054] The domain service is restricted to process the direct domain event through the event processing module.

[0055] Optionally, the architecture further includes a base layer, and the base layer further includes: a batch operation module and a database;

[0056] Providing an access interface to the database through the base layer, so that the target domain model in the domain layer can access the database when running;

[0057] Implementing the transaction through the base layer;

[0058] The batch operation module is used to combine the read and write operations corresponding to multiple databases into batch tasks.

[0059] An embodiment of the present application further discloses an electronic device, comprising: a processor; and a memory on which executable code is stored. When the executable code is executed, the processor executes the data processing method described in the embodiment of the present application.

[0060] The embodiments of the present application also disclose one or more machine-readable media on which executable codes are stored. When the executable codes are executed, the processor executes the data processing method as described in the embodiments of the present application.

[0061] The embodiments of the present application include the following advantages:

[0062] In an embodiment of the present application, a domain-driven design architecture is designed, including an interface layer, a logic layer, and a domain layer. The domain layer includes a domain model divided based on at least one of function, data, and business domains, and the domain model is used to encapsulate and implement business logic; the interface layer is used to receive user requests, convert the user requests into command objects, and call the logic layer to process the command objects; the user requests have corresponding business goals; the logic layer is used to call the domain layer according to the command objects to orchestrate business processes and trigger transactions for implementing the business processes; the domain layer is used to call the target domain model from the domain model according to the business process to implement the business goals corresponding to the user requests; wherein, the business process is driven by the business logic in the target domain model.

[0063] The embodiment of the present application standardizes user requests into command objects through the interface layer, so that when adding new business goals, it is only necessary to expand the command type without modifying the underlying model, which significantly reduces the complexity of iteration. Secondly, the domain model is divided into multiple dimensions according to functions, data, and business fields through the domain layer, providing an objective basis for division, avoiding boundary deviations caused by relying on subjective experience in traditional architectures, and the problem of domain models being out of touch with actual business. Moreover, the core business logic is encapsulated through the domain model in the domain layer to ensure centralized maintenance of business rules. In addition, the logic layer is responsible for orchestrating the business processes in the domain layer, without focusing on implementation details. When adapting to changes in demand, it only needs to adjust the orchestration order instead of rewriting the rules. Unified triggering of transactions can avoid the fragmentation problem caused by decentralized transactions in traditional architectures. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Figure 1 This is a schematic diagram of the architecture of a domain-driven design architecture of this application;

[0065] Figure 2 This is a schematic diagram of the structure of an interface layer of the present application;

[0066] Figure 3 This is a schematic diagram of the structure of a logic layer of this application;

[0067] Figure 4 This is a schematic diagram of the structure of a domain layer of this application;

[0068] Figure 5 This is a flowchart of the steps of domain object design in this application;

[0069] Figure 6 It is a flowchart of the steps of a data processing method of the present application;

[0070] Figure 7 It is a structural diagram of a device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0071] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0072] The traditional MVC architecture is difficult to effectively organize complex business logic in scenarios where requirements change frequently. Business code is easily dispersed across various layers, resulting in a lack of cohesion in core business rules and high iterative maintenance costs.

[0073] The domain models in traditional DDD architectures are often complex and feature extensive design details. Developers need to master a wealth of theoretical knowledge, resulting in a high learning curve. Furthermore, relying on manual experience to partition domain models can lead to blurred business boundaries (e.g., overlapping or missing functionality) or over-engineering (e.g., unreasonable levels of abstraction), making the domain model inaccurately mapping actual business needs. Furthermore, there are currently no simplified models or toolchains suitable for beginners, leaving developers to handle numerous domain modeling details on their own.

[0074] Even if a traditional DDD architecture, after years of refinement, can be applied to a specific business domain, it's difficult to migrate and adapt to other business domains. It lacks a dynamic adaptation mechanism for different business scenarios. Furthermore, because the domain model in a traditional DDD architecture is a congested model, both reading and writing suffer from performance issues. Using a congested model in any simple business scenario can lead to poor performance.

[0075] In an embodiment of the present application, a domain-driven design architecture is designed to be applied to business systems in different business scenarios, thereby achieving dynamic adaptation of the architecture in different business scenarios without the need to redesign the architecture for different business scenarios, thereby reducing design costs.

[0076] Reference Figure 1 , is an architectural block diagram of an embodiment of a domain-driven design architecture of the present application, the architecture comprising: an interface layer 101, a logic layer 102, and a domain layer 103;

[0077] The interface layer 101 is used to receive user requests, convert the user requests into command objects, and call the logic layer to process the command objects; the user requests have corresponding business objectives;

[0078] The interface layer in the embodiment of the present application is mainly used to provide an external API interface (Application Programming Interface) for the business system to interact with external systems, and also provides an internal interface for the business system to interact with the client system. It is specifically responsible for parsing and converting the input (user request), obtaining the command object, and calling the logic layer to execute the user's desired instructions (command object).

[0079] The embodiment of the present application standardizes user requests into command objects through the interface layer, so that when adding new business goals, only the command type needs to be expanded without modifying the underlying model, which significantly reduces the iteration complexity.

[0080] The logic layer 102 is used to call the domain layer to orchestrate the business process according to the command object and trigger the transaction for implementing the business process;

[0081] In the embodiment of this application, the logic layer is mainly responsible for executing user commands (command objects), that is, the abstract process of business logic. Unlike the traditional MVC architecture, in this embodiment of the application, only the business processes in the domain layer are orchestrated and transactions are managed, rather than focusing on implementation details.

[0082] Specifically, orchestrating business processes means that the logic layer uses the business domain components of the domain layer to complete cross-domain business process orchestration.

[0083] The logic layer in the embodiment of the present application is responsible for orchestrating the business processes in the domain layer without focusing on implementation details. When adapting to changes in demand, it only needs to adjust the orchestration order rather than rewriting the rules. Unified triggering of transactions can avoid the fragmentation problem caused by decentralized transactions in traditional architectures.

[0084] The domain layer 103 includes a domain model divided based on at least one of function, data and business domains, and the domain model is used to encapsulate and implement business logic;

[0085] The domain layer 103 is used to call the target domain model from the domain model according to the business process to achieve the business goal corresponding to the user request; wherein the business process is driven by the business logic in the target domain model.

[0086] The domain layer in the embodiment of the present application includes different domain models divided according to business scenarios. The functions of each model are cohesive and only focus on the scope of responsibilities assigned to the domain model without direct dependence on other domain models. Notifications are made in the form of synchronously published events. The decoupling between different domain models is specifically achieved by the event scheduler, which ensures loose coupling between domain models and improves the scalability and maintainability of the architecture.

[0087] The key point of the domain layer is how to divide the domain responsibilities corresponding to different domain models to ensure dynamic adaptation in different business scenarios. As an example, the domain model can be divided based on at least one of the functions, data and business domains.

[0088] It should be noted that the event dispatcher is primarily responsible for delivering domain events between different domain models, ensuring asynchronous and decoupled communication between them. For example, when the "Order Management" domain model completes order creation, it publishes an "Order Created Event." The event dispatcher passes this event to the "Inventory Management" domain model, triggering an inventory update.

[0089] The embodiment of the present application divides the domain model into multiple dimensions according to functions, data, and business domains through the domain layer, providing an objective basis for division, avoiding boundary deviations caused by reliance on subjective experience in traditional architectures, and the problem of disconnection between the domain model and actual business. In addition, the core business logic is encapsulated through the domain model in the domain layer to ensure centralized maintenance of business rules.

[0090] Through clear division of responsibilities, each domain model focuses solely on its own business logic, avoiding the fragmented and duplicative business logic found in traditional architectures. For example, the "Payment Management" domain model is responsible only for payment-related logic and does not involve order or inventory management.

[0091] The design of the domain layer enables the business system to dynamically adjust the responsibilities and interaction methods of the domain model according to changes in business needs without the need for large-scale reconstruction of the entire domain-driven design architecture.

[0092] The domain layer calls the target domain model from the domain model according to the business process to achieve the business goals corresponding to the user request. The business process is driven by the business logic in the target domain model, ensuring the clarity and traceability of the business logic. In this way, the business system using the domain-driven design architecture designed in the embodiment of the present application can better adapt to the changes in demand in complex business scenarios while maintaining the independence and reusability of the domain model.

[0093] The design of the domain layer in the embodiment of the present application not only improves the flexibility and maintainability of the business system, but also ensures a high degree of consistency between the domain model and the actual business.

[0094] In one embodiment of the present application, referring to Figure 2 , is a schematic diagram of the structure of an interface layer of the present application. The interface layer 101 includes: an input data verification module 201, a protocol adaptation module 202, and an output data encapsulation module 203; the interface layer is used to receive user requests and convert the user requests into command objects, including:

[0095] The input data verification module 201 is used to perform data verification on the user request; the user request is sent by an external system or an internal client;

[0096] The protocol adaptation module 202 is used to provide the communication protocol corresponding to the external system or the internal client;

[0097] The output data encapsulation module 203 is used to encapsulate the user request after data verification according to the communication protocol to obtain the command object.

[0098] In the embodiment of the present application, the interface layer is equivalent to a bridge between the business system and the external system or internal client, and is responsible for receiving user requests and converting them into command objects.

[0099] The input data validation module verifies user requests to ensure their legitimacy and integrity. The protocol adapter module provides communication protocols (such as HTTP, gRPC, and WebSocket) corresponding to external systems or internal clients to adapt to different requirements and ensure data consistency. The output data encapsulation module encapsulates verified user requests according to the communication protocol and generates command objects.

[0100] Specifically, user requests from external systems or internal clients are input into the input data validation module, which performs data validation on the user data. For example, it checks whether the type, format, and range of the user request meet the requirements, verifies whether required fields exist, and verifies whether the data complies with business rules. If the validation fails, an error message is returned; if the validation passes, the user request is passed to the protocol adaptation module. The protocol adaptation module selects the appropriate adaptation protocol based on the source of the user request and converts the user request from the protocol-specific format to the unified data format within the business system. The output data encapsulation module receives the user request processed by the protocol adaptation module and encapsulates the user request into a command object.

[0101] As an example, the command object can be understood as a unified interface for processing business logic within the business system, which is convenient for subsequent logic layer calls and can contain the target operation, parameters and context information requested by the user.

[0102] The interface layer in the embodiments of this application separates communication protocol-related processing from business logic through a protocol adapter module and an output data encapsulation module, improving the flexibility and maintainability of the business system. The input data validation module ensures the legitimacy of request data and prevents invalid or malicious data from entering the system. By encapsulating command objects, a unified interface is provided for the logic layer, simplifying the implementation and expansion of business logic.

[0103] In one embodiment of the present application, referring to Figure 3 , is a schematic diagram of the structure of a logic layer of the present application. The logic layer 102 includes: a decomposition module 301, an assembly module 302, and an orchestration module 303. The logic layer is used to call the domain layer to orchestrate the business process according to the command object, including:

[0104] The decomposition module 301 is used to decompose the command object to obtain multiple sub-operations;

[0105] The assembling module 302 is used to determine the operation sequence of multiple sub-operations and assemble the multiple sub-operations into business steps according to the operation sequence;

[0106] The orchestration module 303 is used to call the domain layer to orchestrate the business process according to the business steps; the business process is executed by multiple sub-operations in the operation sequence.

[0107] In the embodiment of the present application, the logic layer is responsible for converting the command objects delivered by the interface layer into specific business processes and achieving business goals by calling the domain layer.

[0108] The logic layer obtains the encapsulated command object from the interface layer, decomposes the command object into multiple sub-operations through the decomposition module, determines the execution order and dependencies of the sub-operations through the assembly module, calls the domain layer through the orchestration module, and executes the business process step by step.

[0109] Specifically, the decomposition module parses the business objectives (e.g., "create order") in the command object and breaks them down into executable sub-operations based on business rules. For example, "create order" can be decomposed into executable sub-operations such as verifying inventory, deducting inventory, generating an order, and triggering payment. The assembly module determines the execution order of sub-operations based on business logic (e.g., inventory must be verified before deducting inventory), handles dependencies between sub-operations (e.g., payment must be triggered after order generation), and then sequentially combines sub-operations into a coherent business process. For example, verify inventory → deduct inventory → generate order → trigger payment. This can be simply understood as defining the order of steps and dependencies when writing a script. The orchestration module sequentially calls the target domain models in the domain layer (e.g., "inventory model," "order model," and "payment model") based on the business steps and ensures the transactional nature of the business process, such as triggering distributed transactions during cross-domain operations (e.g., inventory deductions and payments must remain consistent).

[0110] As an example, in an embodiment of the present application, the domain-driven design architecture and the event-driven architecture are combined, and the orchestration module can trigger domain events through the event scheduler, for example, the "inventory deduction event" notifies the "payment model".

[0111] In an embodiment of the present application, a new transaction will be opened in the logic layer. According to the received command object, it will be split and assembled into objects of different business domains (business steps). According to the business logic, the APIs of different domain layers will be called, and the corresponding domain objects in the domain layer will be passed in to complete the business logic execution of the domain. The results returned by each domain layer will then be encapsulated and output back to the interface layer.

[0112] There are generally two assembly methods in the assembly module: one is that if the command object contains the complete fields required in the business domain, the assembly can be assisted by a technical framework similar to mapstruct; the other is that if the command object only contains reference fields in the business domain, the query API of the corresponding domain layer is used for assembly.

[0113] It should be noted that the core of implementing business process orchestration in the embodiments of this application lies in the fact that the API provided by the domain layer must have sufficient atomicity and cohesion. Atomicity ensures that a simple business can be completed while also participating in complex businesses through orchestration, making the code more reusable and reducing the amount of modification when requirements change; cohesion aims to increase the modularity of business logic and reduce the coupling of business systems.

[0114] Compared with the traditional MVC three-tier architecture, the logic layer in the embodiment of the present application no longer needs to consider how to maintain the structural relationship of each business object. It only needs to focus on the orchestration of business processes without paying attention to the implementation details, which improves the logical reusability of each business module and reduces the complicated parameter verification, which is integrated into the domain objects of the domain layer.

[0115] The decomposition module and assembly module in the embodiment of the present application separate business rules from process control, so that modifications to business rules do not need to affect process orchestration. By adjusting the order of operations in the assembly module, you can quickly respond to changes in demand (for example, adding a "coupon verification" step). The orchestration module uniformly manages cross-domain operations and avoids the fragmentation problem caused by the dispersion of transactions in the traditional architecture. When adding new business scenarios, you only need to expand the decomposition and assembly logic without modifying the domain model.

[0116] In one embodiment of the present application, referring to Figure 4 , is a schematic diagram of the structure of a domain layer of the present application. The domain layer 103 includes a business domain model, a domain division module 401, a model selection module 402, and a logic execution module 403. The domain model includes domain objects. The domain layer is used to call the target domain model from the domain model according to the business process to achieve the business goal corresponding to the user request, including:

[0117] The domain division module 401 is used to divide the business domain model into multiple domain models according to business functions; and / or, divide the business domain model into multiple domain models according to the type, source and storage method of business data; and / or, divide the business domain model into multiple domain models according to business domains;

[0118] The model selection module 402 is used to match the target domain model from the domain model according to the business process;

[0119] The logic execution module 403 is used to execute the business logic in the target domain model through the domain objects in the target domain model to achieve the business goal corresponding to the user request.

[0120] The domain layer in the embodiment of the present application is the core business logic implementation layer of the business system, which is responsible for calling the target domain model according to the business process and executing the business logic through the domain objects.

[0121] Divide the system into multiple domain models (such as order model, inventory model) according to functions, data or business domains. According to the sub-operations in the business process, match the target domain model, call the domain objects of the target model to execute business logic, and ultimately achieve the goals requested by the user.

[0122] In the embodiment of the present application, the domain division principles followed in the domain division module are as follows:

[0123] 1) Functional Division: This division is based on the business functions of the business system. Each domain model is responsible for implementing a specific function. This division method is usually used in systems with clear business logic and relatively independent functional areas. For example: payment model, user management model, order model, permission model, etc.

[0124] 2) Data Partitioning: Data is partitioned based on type, source, and storage method. Each domain model is responsible for only the data it needs, making it suitable for data-driven systems. By separating data sources and data management, each domain model focuses solely on processing and storing its own data.

[0125] The embodiments of the present application ensure that each domain model only focuses on its own business logic and data storage through clear functional division and data division, thereby reducing coupling between modules, improving the maintainability and scalability of the business system, reducing data dependencies across models, making the model more efficient during operation, and reducing the overall failure rate of the business system.

[0126] 3) Business domain division: The business system is divided into business domains and sub-domains, and each sub-domain is regarded as an independent domain model. It is suitable for systems with complex and changing businesses, and emphasizes the formation of a complete domain model in each domain.

[0127] It should be noted that Domain-Driven Design is a typical division method based on business domains. It ensures consistency within the domain by defining "Bounded Context" and "Aggregate Root".

[0128] The embodiments of the present application divide the business domains based on the concepts of "bounded context" and "aggregate root" to ensure data consistency and encapsulation of business logic in each domain of the business system, thereby reducing cross-domain interference and enhancing the stability and flexibility of the business system.

[0129] 4) Cohesion Partitioning: Partitioning is based on the cohesion within the model. If the functions within the model are strongly related, they can be divided into a domain model. Functions with high cohesion should be placed in the same domain, while functions with low cohesion should be split into independent domains. This is often seen in componentized or modular system design to ensure clear functions and responsibilities within each module.

[0130] The embodiments of the present application ensure the cohesion of domain objects, closely combine the attributes and behaviors of objects, avoid excessive or overly dispersed responsibilities, and thus improve the readability and maintainability of the code.

[0131] 5) Reusability: Reusability between models is also an important factor in model division. If a domain model has high reuse value, consider separating it into a separate domain model. For example, modules such as identity authentication, payment, and logging generally have high reusability and are suitable for management as independent domain models.

[0132] The embodiments of the present application provide objective division criteria through the above-mentioned division principles, which can avoid boundary ambiguity or over-design caused by human experience and ensure that each domain model has cohesive functions and single responsibilities.

[0133] The model selection module analyzes the sub-operation's goals and parameters to determine the domain model to call. For example, the "deduct inventory" operation matches the "inventory domain model," while the "generate order" operation matches the "order domain model."

[0134] In the embodiments of the present application, different business scenarios can be dynamically adapted, domain models can be flexibly called, and business expansion can be supported without modifying the core logic when adding new domain models.

[0135] It should be noted that a domain object is a core concept in domain-driven design. It represents a business concept or entity and is usually used to encapsulate and express business rules, behaviors, and data in a business system. It refers to a specific component in the domain model and follows the following design principles:

[0136] 1) Domain objects should directly express important concepts in the business domain and should not be coupled with technical details. Their attributes and behaviors should accurately reflect the core content of the business problem.

[0137] 2) A domain object should have high cohesion, that is, its properties and methods should be closely related to its own business responsibilities, avoiding the design of domain objects that are too large or have too many responsibilities.

[0138] 3) Domain objects should encapsulate their internal state and behavior as much as possible. Only when external access to their state is required should interfaces be provided through public methods to avoid directly exposing data attributes and reduce external dependence on domain objects.

[0139] 4) Each domain object should have a unique identifier (ID) to distinguish different entities. The ID can be natural, such as a social security number, order number, etc., or a unique identifier generated by the business system.

[0140] 5) Domain objects not only store data, but also include business-related behaviors. The design of behaviors should follow business logic, avoid excessive separation of behaviors from data, and ensure that business rules are concentrated within domain objects.

[0141] 6) When designing, you need to consider whether the state of domain objects needs to change during the life cycle. Some domain objects (such as "value objects") may be immutable, while the state of other domain objects (such as "entities") may change.

[0142] 7) In domain-driven design, aggregate root is an important concept, which refers to the root entity within an aggregate. The aggregate root is responsible for ensuring the consistency within the aggregate. External systems usually access the functions of the entire aggregate through the aggregate root rather than directly accessing other root entities within the aggregate.

[0143] In the embodiments of this application, domain objects can be divided into the following categories:

[0144] 1) Entity: An entity is an object with a unique identifier, whose lifecycle is managed by the system. An entity's identifier distinguishes it from other entities, and entities typically change over time within a business system. For example, in an e-commerce system, orders, users, and products are all entity objects.

[0145] 2) Value Object: A value object is an object without a unique identifier, typically representing some simple business concept. The key characteristic of a value object is immutability; changing the state of a value object usually means creating a new value object. For example, in an e-commerce system, addresses, order items (such as quantity and price), and payment methods can serve as value objects.

[0146] 3) Aggregate: An aggregate is a collection of related domain objects, typically represented and managed by an aggregate root. The aggregate root ensures the consistency of all entities and value objects within the aggregate at a given moment. For example, an order (aggregate root) may contain multiple order items (entities), and the behavior and state changes of these order items are controlled by the order (aggregate root).

[0147] 4) Domain Service: Domain services provide functionality for specific business operations, typically encapsulating the operations of multiple domain objects. Domain services do not directly contain state; instead, they primarily provide the behavior for handling a specific business process or operation. For example, in an e-commerce system, order processing services (such as payment and shipping) can coordinate order and payment domain objects.

[0148] 5) Domain Event: Domain events represent business-significant events that occur within a domain. Domain events notify other parts of the business system of a state change and are often used to implement event-driven architectures (EDA). For example, in e-commerce systems, "Order successfully paid" or "Product shipped" are typical domain events.

[0149] The embodiments of the present application make the processing of business logic more centralized and orderly through the introduction of aggregate roots and the management of domain events, while achieving loose coupling and asynchronous processing between modules through the mechanism of domain events.

[0150] Compared with the traditional DDD architecture, the embodiments of the present application can not only achieve a clear division of business areas, but also achieve a comprehensive improvement in the performance, scalability and consistency of the business system through performance optimization, transaction management and event-driven mechanisms.

[0151] Reference Figure 5 , is a flowchart of the steps of domain object design in this application, which specifically includes the following steps:

[0152] Step 501: Identify core domain concepts in the business system. These concepts can usually be mapped to domain objects.

[0153] Step 502: Based on the domain analysis results, identify entities that require unique identifiers and value objects that do not have identifiers, and determine the responsibilities and behaviors of each domain object.

[0154] Step 503: Determine which entities and objects are part of the aggregate and decide which entity is the aggregate root. The aggregate root is responsible for the business logic and consistency within the aggregate.

[0155] Step 504: Convert the business rules into methods and behaviors of domain objects. Domain objects should be responsible for business logic, not just data storage.

[0156] Step 505: For complex operations across multiple domain objects, domain services may need to be introduced. Services do not belong to a specific entity or value object, but abstract operations on multiple domain objects.

[0157] Step 506: For business operations that need to trigger notifications or reactions, consider using domain events to notify other parts of the business system.

[0158] Step 507: During the actual development process, continuously optimize the domain model to ensure that the domain objects can truly reflect business needs.

[0159] The logic execution module receives the target domain model determined by the model selection module and calls the corresponding domain objects in the model to execute business logic (such as updating inventory and generating order records).

[0160] In this application, the domain partitioning module achieves physical isolation of business logic, allowing each domain model to evolve independently. The logic execution module ensures that business logic is centrally implemented and maintained in domain objects, avoiding code redundancy to ensure high cohesion and reusability. Domain object encapsulation rules prevent the fragmentation of business code.

[0161] In one embodiment of the present application, the domain model includes domain objects, such as Figure 4 As shown, the domain layer 103 further includes a lazy loading module 404, a cache module 405 and an object reuse module 406;

[0162] The lazy loading module is used to adopt a lazy loading mechanism for a first domain object that does not need to be loaded immediately among the domain objects, and load the data corresponding to the first domain object only when the first domain object is accessed;

[0163] The cache module is used to cache the second domain object whose access frequency is higher than the preset frequency threshold among the domain objects, so that the data corresponding to the second domain object is directly used when the second domain object is accessed;

[0164] The object reuse module is used to reuse the third domain object whose creation cost is higher than a preset cost threshold in the domain objects and to share the fourth domain object that is not allowed to be modified in the domain objects.

[0165] To improve the performance and resource utilization of the business system, the domain layer introduces the following three modules to optimize the loading, caching, and reuse of domain objects.

[0166] The domain objects of a rich model (domain model) usually contain other dependent attributes or objects. At this time, the lazy loading module can be used to adopt a lazy loading mechanism for attributes or objects that do not need to be loaded immediately (first domain objects). For example, the Lambda expression of the Supplier interface in Java can ensure that its data is loaded only when the object is actually accessed. In some simple business scenarios, domain objects can be used directly to ensure the consistency of the business system.

[0167] As an example, the lazy loading module can load only core data (such as order ID, user ID) when initializing domain objects, and load related data (such as order item lists) only when called to implement a lazy loading mechanism; it can also use proxy objects to take place and trigger data loading when actually accessed to implement a lazy loading mechanism.

[0168] The lazy loading module is suitable for scenarios where the amount of data in the domain objects is large or the loading cost is high, or some data may not be accessed in the business process. For example, the "historical evaluation" field of an order is only loaded when viewing the details. This can reduce the initial loading time, optimize memory usage, and avoid unnecessary database queries or network requests.

[0169] However, using only the lazy loading mechanism to achieve performance optimization is far from enough, because external systems may frequently access domain objects, and even the lazy loading mechanism may require multiple reads and writes to the database, resulting in performance degradation. Therefore, in the embodiments of the present application, by combining caching technology, direct caching after the first calculation is performed to avoid repeated calculations, such as the MemoizingSupplier in the guava toolkit. Specifically, the present application can quickly determine whether the domain object is a frequently accessed object by comparing the access frequency with a preset threshold.

[0170] As an example, the cache module may adopt an LRU (least recently used) or TTL (time to live) strategy to manage the cache, and automatically refresh or invalidate the cache when the underlying data is updated.

[0171] The cache module is suitable for second-domain objects that are accessed frequently, such as "product details" that are frequently queried during promotions. This can reduce the pressure on the database or external services, improve response speed, and support performance stability in high-concurrency scenarios.

[0172] The embodiments of the present application optimize the performance of the business system by combining a lazy loading mechanism and a caching mechanism, avoid frequent database access and repeated calculations, and improve the response speed and efficiency of the business system.

[0173] In actual applications, excessive creation of domain objects increases memory usage and the burden of garbage collection. Therefore, in an embodiment of the present application, domain objects are reused through an object reuse module to avoid repeated creation of high-cost third domain objects. For immutable fourth domain objects, repeated creation can be avoided by sharing. The present application can quickly determine whether a domain object is a high-cost object by using the creation cost and a preset cost threshold.

[0174] The object reuse module is suitable for high-cost third-domain objects, such as domain objects that require complex calculations, and is also suitable for immutable fourth-domain objects, such as value objects (such as "delivery address" and "currency exchange rate").

[0175] As an example, you can maintain a pool of reusable objects to reuse domain objects and avoid repeated creation (such as a database connection pool). You can also share immutable objects so that multiple requests share the same instance (such as "distribution rules"), reducing resource consumption (CPU, memory) for object creation and destruction, and ensuring the global consistency of immutable objects to avoid data redundancy.

[0176] The embodiment of the present application reuses high-cost objects and shared immutable objects through the object pool mode, reduces memory usage and garbage collection burden, and improves the performance of the business system.

[0177] In one embodiment of the present application, the domain model includes domain objects, which include domain services that provide operations and domain events that represent business significance within the domain model. The domain services are used to process the domain events. The domain events include direct domain events directly associated with the domain services and indirect domain events indirectly associated with the domain services. The domain layer also includes an event binding module 407 and an event processing module 408.

[0178] The event binding module is used to bind the domain event to the target phase of the transaction when the domain event is published; the target phase is used to represent the time point when the domain event is triggered;

[0179] The event processing module is used to limit the domain service to process the direct domain event.

[0180] As mentioned above, domain objects include domain services and domain objects. Domain events also include direct domain events and indirect domain events. Direct domain events refer to events directly triggered by the current domain service (for example, "payment service" triggers "payment success event"). Indirect domain events refer to events triggered by other domain services but require a response from the current domain service (for example, "order service" triggers "order creation event" and "inventory service" listens to and processes the event).

[0181] In a common synchronous event scheduler, once the publisher publishes an event, the listener will immediately receive the event and process it, such as updating the cache. However, the transaction may not be completed at this time. If the transaction fails after updating the cache, the updated cache cannot be rolled back, and most cache frameworks or middleware do not have transaction capabilities. Therefore, in an embodiment of the present application, when the domain event is published, the domain event is bound to the target phase of the transaction through the event binding module to ensure that the event is triggered at the correct time point of the transaction. The target phase refers to the time point when the domain event is triggered, for example, before the transaction is committed or after the transaction is committed.

[0182] As an example, you can use an event listener like the @TransactionalEventListener provided by Spring to customize the event processing logic to execute at the appropriate time.

[0183] As an example, if the domain event is an event that needs to be processed synchronously with the transaction (such as a rollback event triggered when data verification fails), the target stage is defined as before the transaction is committed; if the domain event is an event that needs to ensure data consistency (such as an "order creation event" that is only triggered after the transaction is committed to avoid dirty data), the target stage is defined as after the transaction is committed.

[0184] The embodiment of the present application can ensure strict synchronization between event triggering and transaction stage through the event binding module, prevent data inconsistency, and support atomic processing of transactional events. It uses Spring's @TransactionalEventListener to solve the event processing problem after transaction submission. In complex business scenarios, it ensures data consistency when the transaction is rolled back, avoiding the inconsistency problems caused by traditional synchronous event scheduling.

[0185] In an architecture using domain events, if the division of domain responsibilities is unreasonable, it may lead to infinite event loops and stack overflow errors. Therefore, the embodiment of the application follows the principle of domain responsibility division through the event processing module, that is, domain services only process directly related domain events, to avoid the proliferation of domain responsibilities.

[0186] Specifically, domain services only handle directly related directly related events and ignore indirectly related indirectly related events.

[0187] For example, in an IoT system, a device is bound to an alarm policy, and the alarm policy is bound to a notification policy. When the device is deleted, the domain service of the notification policy only pays attention to the domain events of the directly associated alarm policy, and does not pay attention to the domain events of the device.

[0188] The embodiment of the present application reasonably divides the responsibilities of domain services through the event processing module, avoids unnecessary event loop propagation, and can ensure that domain events are propagated downward in a chain rather than upward to form a loop, making the processing of business logic clearer, reducing potential stack overflow errors, and ensuring that the system does not enter an infinite loop when processing domain events, effectively avoiding the confusion problems in traditional domain service interactions.

[0189] In one embodiment of the present application, Figure 1 As shown, the architecture further includes a base layer 104, which includes: a batch operation module and a database;

[0190] The base layer is used to provide an access interface to the database, so that the target domain model in the domain layer can access the database when running;

[0191] The base layer is also used to implement the transaction;

[0192] The batch operation module is used to merge the read and write operations corresponding to multiple databases into batch tasks.

[0193] In the embodiment of the present application, the basic layer is the underlying infrastructure support layer of the business system, which is responsible for providing core capabilities such as data persistence, transaction management, and batch operations. Through standardized interfaces and optimization mechanisms, it ensures that the upper-level business logic (such as the domain layer) can access and operate data efficiently and securely.

[0194] The database, as the data storage core of the business system, is responsible for persisting business data (such as orders, users, inventory, etc.). The foundation layer provides a unified database access interface (such as the DAO layer or Repository interface) and encapsulates specific database operations (such as CRUD).

[0195] The target domain model in the domain layer accesses the database through the access interface provided by the base layer, without directly processing database connections or SQL (Structured Query Language) statements.

[0196] As an example, the order model saves order data through the OrderRepository.save(order) method of the base layer.

[0197] The infrastructure layer manages transactions, ensuring the atomicity and consistency of operations. For local transactions within a single database, the database's ACID (Atomicity-Consistency-Isolation-Durability) properties can be leveraged for transaction management (e.g., MySQL's BEGIN TRANSACTION and COMMIT). For distributed transactions across multiple databases or services, the Saga pattern or two-phase commit (2PC) might be used for transaction management. The infrastructure layer centrally controls the initiation, commit, and rollback of transactions, typically working in conjunction with the process orchestration module of the logic layer.

[0198] In an embodiment of the present application, a batch operation module is used to merge operations of multiple databases into batch tasks to reduce database connection overhead and network transmission times, thereby improving the throughput of the business system. It is suitable for high-concurrency write scenarios (such as inventory updates for e-commerce flash sale activities).

[0199] Based on the above embodiments, this embodiment further provides a data processing method, which is applied to electronic devices such as terminal devices and servers.

[0200] Reference Figure 6 , shows a flow chart of steps of an embodiment of a data processing method of the present application, the data processing method is applied to the above-mentioned domain-driven design architecture, such as Figure 1 As shown, the domain-driven design architecture includes: an interface layer 101, a logic layer 102, and a domain layer 103. The domain layer 103 includes a domain model divided based on at least one of function, data, and business domains. The domain model is used to encapsulate and implement business logic, and specifically may include the following steps:

[0201] Step 601: Receive a user request through the interface layer, convert the user request into a command object, and call the logic layer to process the command object; the user request has a corresponding business goal;

[0202] Step 602: The logic layer calls the domain layer to orchestrate a business process according to the command object, and triggers a transaction for implementing the business process.

[0203] Step 603: Call the target domain model from the domain model through the domain layer according to the business process to achieve the business goal corresponding to the user request; wherein the business process is driven by the business logic in the target domain model.

[0204] In the embodiment of the present application, the method description of the above steps 601 to 603 is the same as the description of the above domain-driven design architecture. For detailed description, please refer to the above content and will not be repeated here.

[0205] It should be noted that for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present application are not limited by the order of the actions described, because according to the embodiments of the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present application.

[0206] An embodiment of the present application further provides a non-volatile readable storage medium, which stores one or more modules (programs). When the one or more modules are applied to a device, the device can execute instructions (instructions) of each method step in the embodiment of the present application.

[0207] An embodiment of the present application provides an electronic device, including a processor and a memory; and the memory stores executable code, which, when executed, enables the processor to execute the data processing method described in the above embodiment. The electronic device includes various types of devices such as terminal devices and servers (clusters).

[0208] The embodiments of the present application provide one or more machine-readable media on which executable codes are stored. When the executable codes are executed, the processor executes the data processing method described in the above embodiments.

[0209] The embodiments of the present disclosure may be implemented as a device configured as desired using any appropriate hardware, firmware, software, or any combination thereof, and the device may include electronic devices such as terminal devices and servers (clusters). Figure 7 An exemplary apparatus 700 that can be used to implement various embodiments described in this application is schematically illustrated.

[0210] For one embodiment, Figure 7 An exemplary apparatus 700 is shown having one or more processors 702, a control module (chip set) 704 coupled to at least one of the processor(s) 702, a memory 706 coupled to the control module 704, a non-volatile memory (NVM) / storage device 708 coupled to the control module 704, one or more input / output devices 710 coupled to the control module 704, and a network interface 712 coupled to the control module 704.

[0211] The processor 702 may include one or more single-core or multi-core processors, and the processor 702 may include any combination of general-purpose processors or dedicated processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, the apparatus 700 can serve as a terminal device, server (cluster), or other device described in the embodiments of the present application.

[0212] In some embodiments, the apparatus 700 may include one or more computer-readable media (e.g., memory 706 or NVM / storage 708) having instructions 714 and one or more processors 702 configured in conjunction with the one or more computer-readable media to execute the instructions 714 to implement a module to perform the actions described in the present disclosure.

[0213] For one embodiment, the control module 704 may include any suitable interface controller to provide any suitable interface to at least one of the processor(s) 702 and / or any suitable device or component in communication with the control module 704 .

[0214] The control module 704 may include a memory controller module to provide an interface to the memory 706. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0215] The memory 706 can be used, for example, to load and store data and / or instructions 714 for the device 700. For one embodiment, the memory 706 can include any suitable volatile memory, such as a suitable DRAM. In some embodiments, the memory 706 can include double data rate type four synchronous dynamic random access memory (DDR4 SDRAM).

[0216] For one embodiment, the control module 704 may include one or more input / output controllers to provide interfaces to the NVM / storage device 708 and the input / output device(s) 710 .

[0217] For example, NVM / storage 708 may be used to store data and / or instructions 714. NVM / storage 708 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable non-volatile storage device(s) (e.g., one or more hard disk drives (HDDs), one or more compact disk (CD) drives, and / or one or more digital versatile disk (DVD) drives).

[0218] NVM / storage device 708 may include storage resources that are physically part of the device on which apparatus 700 is installed, or it may be accessible to the device without being part of the device. For example, NVM / storage device 708 may be accessible over a network via input / output device(s) 710.

[0219] (One or more) input / output devices 710 may provide an interface for apparatus 700 to communicate with any other appropriate devices. Input / output devices 710 may include communication components, audio components, sensor components, etc. Network interface 712 may provide an interface for apparatus 700 to communicate via one or more networks. Apparatus 700 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, for example, accessing a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G, 5G, etc., or a combination thereof for wireless communication.

[0220] For one embodiment, at least one of the processor(s) 702 may be packaged together with the logic of one or more controllers (e.g., a memory controller module) of the control module 704. For one embodiment, at least one of the processor(s) 702 may be packaged together with the logic of one or more controllers of the control module 704 to form a system-in-package (SiP). For one embodiment, at least one of the processor(s) 702 may be integrated on the same die with the logic of one or more controllers of the control module 704. For one embodiment, at least one of the processor(s) 702 may be integrated on the same die with the logic of one or more controllers of the control module 704 to form a system-on-chip (SoC).

[0221] In various embodiments, the apparatus 700 may be, but is not limited to, a terminal device such as a server, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a tablet computer, a netbook, etc.). In various embodiments, the apparatus 700 may have more or fewer components and / or a different architecture. For example, in some embodiments, the apparatus 700 includes one or more cameras, a keyboard, a liquid crystal display (LCD) screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0222] Among them, the main control chip can be used as a processor or control module in the detection device, sensor data, location information, etc. are stored in the memory or NVM / storage device, the sensor group can be used as an input / output device, and the communication interface may include a network interface.

[0223] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0224] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0225] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable terminal device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0226] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0227] These computer program instructions can also be loaded onto a computer or other programmable terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0228] Although preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic inventive concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0229] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0230] The above is a detailed introduction to a domain-driven design architecture and data processing method, an electronic device and a storage medium provided by this application. Specific examples are used in this article to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method of this application and its core idea; at the same time, for general technical personnel in this field, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on this application.

Claims

1. A domain-driven design architecture, comprising: Interface layer, logic layer and domain layer; The domain layer includes a domain model divided based on at least one of function, data and business domains, and the domain model is used to encapsulate and implement business logic; The interface layer is used to receive user requests, convert the user requests into command objects, and call the logic layer to process the command objects; the user requests have corresponding business objectives; The logic layer is used to call the domain layer to orchestrate the business process according to the command object and trigger the transaction for implementing the business process; The domain layer is used to call the target domain model from the domain model according to the business process to achieve the business goal corresponding to the user request; wherein the business process is driven by the business logic in the target domain model.

2. The architecture according to claim 1, wherein: The interface layer includes: an input data verification module, a protocol adaptation module and an output data encapsulation module; the interface layer is used to receive user requests and convert the user requests into command objects, including: The input data verification module is used to perform data verification on the user request; the user request is sent by an external system or an internal client; The protocol adaptation module is used to provide the communication protocol corresponding to the external system or the internal client; The output data encapsulation module is used to encapsulate the user request after data verification according to the communication protocol to obtain the command object.

3. The architecture according to claim 1, wherein: The logic layer includes: a decomposition module, an assembly module and an orchestration module; the logic layer is used to call the domain layer to orchestrate the business process according to the command object, including: The decomposition module is used to decompose the command object to obtain multiple sub-operations; The assembling module is used to determine the operation sequence of multiple sub-operations and assemble the multiple sub-operations into business steps according to the operation sequence; The orchestration module is used to call the domain layer to orchestrate the business process according to the business steps; the business process is executed by multiple sub-operations in the operation sequence.

4. The architecture according to claim 1, wherein: The domain layer includes a business domain model, a domain division module, a model selection module, and a logic execution module. The domain model includes domain objects. The domain layer is used to call the target domain model from the domain model according to the business process to achieve the business goal corresponding to the user request, including: The domain division module is used to divide the business domain model into multiple domain models according to business functions; and / or, divide the business domain model into multiple domain models according to the type, source and storage method of business data; and / or, divide the business domain model into multiple domain models according to business domains; The model selection module is used to match the target domain model from the domain model according to the business process; The logic execution module is used to execute the business logic in the target domain model through the domain objects in the target domain model to achieve the business goal corresponding to the user request.

5. The architecture according to claim 1, wherein: The domain model includes domain objects, and the domain layer also includes a lazy loading module, a cache module and an object reuse module; The lazy loading module is used to adopt a lazy loading mechanism for a first domain object that does not need to be loaded immediately among the domain objects, and load the data corresponding to the first domain object only when the first domain object is accessed; The cache module is used to cache the second domain object whose access frequency is higher than the preset frequency threshold among the domain objects, so that the data corresponding to the second domain object is directly used when the second domain object is accessed; The object reuse module is used to reuse the third domain object whose creation cost is higher than a preset cost threshold in the domain objects and to share the fourth domain object that is not allowed to be modified in the domain objects.

6. The architecture according to claim 1, wherein: The domain model includes domain objects, which include domain services that provide operations and domain events that are used to represent business significance within the domain model. The domain services are used to process the domain events. The domain events include direct domain events directly associated with the domain services and indirect domain events indirectly associated with the domain services. The domain layer also includes an event binding module and an event processing module. The event binding module is used to bind the domain event to the target phase of the transaction when the domain event is published; The target phase is used to represent the time point when the domain event is triggered; The event processing module is used to limit the domain service to process the direct domain event.

7. The architecture according to claim 1, wherein: The architecture also includes a base layer, which includes: a batch operation module and a database; The base layer is used to provide an access interface to the database, so that the target domain model in the domain layer can access the database when running; The base layer is also used to implement the transaction; The batch operation module is used to merge the read and write operations corresponding to multiple databases into batch tasks.

8. A data processing method, applied to the domain-driven design architecture according to any one of claims 1 to 7, characterized in that: The architecture includes: an interface layer, a logic layer, and a domain layer; the domain layer includes a domain model divided based on at least one of function, data, and business domains, and the domain model is used to encapsulate and implement business logic. The method includes: receiving a user request through the interface layer, converting the user request into a command object, and calling the logic layer to process the command object; the user request has a corresponding business goal; Calling the domain layer to orchestrate a business process according to the command object through the logic layer, and triggering a transaction for implementing the business process; The target domain model is called from the domain model through the domain layer according to the business process to achieve the business goal corresponding to the user request; wherein the business process is driven by the business logic in the target domain model.

9. An electronic device, characterized in that: include: processor; and A memory having executable codes stored thereon, which, when executed, causes the processor to execute the data processing method as claimed in claim 8.

10. One or more machine-readable media having executable codes stored thereon, which, when executed, cause a processor to perform the data processing method as claimed in claim 8.

Images