Financial field code architecture design method and system based on field-driven design

Abstract

The invention provides a financial domain code architecture design method and system based on domain-driven design. The method comprises the steps of user interface layer design, infrastructure layer design, domain layer design and application layer design. In the step of designing the user interface layer, the user interface layer used for interacting with a user is constructed, and the user interface layer receives input of the user and feeds back a processing result to the user; in the step of designing the infrastructure layer, the infrastructure layer used for providing underlying resource service is constructed, and the infrastructure layer provides a database or message middleware; in the domain layer design step, an entity, a native business model and a domain service in the domain layer are constructed; in the step of designing the application layer, the application layer used for interaction between the domain layer and the user interface layer is constructed, the application layer calls domain layer services or external micro-services, the application layer further comprises an anti-corrosion layer, and the anti-corrosion layer receives data from an external system and converts the data into a format suitable for the domain layer.

Description

Technical Field

[0001] The present invention relates to the technical field of backend code architecture design, and in particular to a financial field code architecture design method and system based on domain driven design. Background Art

[0002] Domain-Driven Design (DDD) is a software design philosophy and methodology that aims to build flexible and maintainable software systems through in-depth understanding of the business domain. Its core idea is to build a software design system with the domain as the core driving force, and abstract the domain model around the business concept. The complex business model is abstracted and simplified through domain and boundary division, and finally the complex software application system is disassembled and encapsulated. DDD includes two levels: strategic design and tactical design. Strategic design mainly starts from the business perspective, establishes business domain models, divides domain boundaries, and establishes bounded contexts of common languages. It focuses on the key points of business strategy and how to best integrate. Tactical design starts from a technical perspective and focuses on the technical implementation of the domain model, including the design and implementation of code logic such as entities, value objects, aggregates, factories, warehouses, domain services, and domain events. It focuses on specific situations and scenarios in the domain to meet business needs.

[0003] DDD can be used not only for microservice design, but also for enterprise mid-tier design and traditional monolithic applications. It emphasizes the domain as the core, and closely integrates business requirements and software architecture through domain models and common languages, so that the software system can better adapt to business changes and has higher flexibility and maintainability.

[0004] The rise of DDD is closely related to the popularity of microservice architecture. People have found that DDD can be used as a powerful tool to divide the boundaries of microservices, and many of its design concepts are highly consistent with microservice architecture.

[0005] In the domain-driven design of the prior art, most of the codes are transaction scripts and the objects are anemic models, which will result in poor code maintainability, poor scalability, and poor testability in the long run. Summary of the invention

[0006] In view of this, an embodiment of the present invention provides a financial domain code architecture design method based on domain-driven design to eliminate or improve one or more defects existing in the prior art.

[0007] One aspect of the present invention provides a method for designing a financial domain code architecture based on domain-driven design, the method comprising steps of user interface layer design, infrastructure layer design, domain layer design, and application layer design;

[0008] In the step of user interface layer design, a user interface layer for interacting with a user is constructed, wherein the user interface layer receives user input and feeds back processing results to the user;

[0009] In the step of infrastructure layer design, an infrastructure layer for providing underlying resource services is constructed, wherein the infrastructure layer provides a database or a message middleware;

[0010] In the step of domain layer design, entities, native business models and domain services in the domain layer are constructed;

[0011] In the application layer design step, an application layer is constructed for interaction between the domain layer and the user interface layer. The application layer calls domain layer services or external microservices. The application layer also includes an anti-corrosion layer, which receives data from external systems and converts it into a format suitable for the domain layer.

[0012] By adopting the above solution, this solution sinks the non-core business concepts, rules and verifications of data objects (Data Object) into the native business model (Domain Primitive), decouples from the data storage layer through the object storage interface class (Repository), adds an anti-corrosion layer (ACL) to the third-party service, abstracts the entity class (Entity) with data and behavior, combines and orchestrates application services through the application layer (Application Service), adapts to changes in business processes, calls domain layer services or external microservices, completes business logic, and ultimately improves the maintainability, scalability and testability of the code.

[0013] In some embodiments of the present invention, the user interface layer is used to process RESTful requests, parse configuration information, and pass it to the application layer.

[0014] In the specific implementation process, the User Interface Layer is responsible for interacting with users, receiving user input and displaying processing results. The User Interface Layer processes RESTful requests, parses configuration information, and passes data assembly to the application layer.

[0015] In some embodiments of the present invention, in the process of the application layer calling the domain layer service or the external microservice, the application layer calls the corresponding domain layer service or the external microservice based on the business processing flow to complete the corresponding data processing.

[0016] In some embodiments of the present invention, in the step of constructing entities, native business models and domain services in the domain layer:

[0017] The entity is used to encapsulate the stateful behavior of a single object, including business verification;

[0018] The native business model is used to encapsulate stateless computing logic that is independent of the entity;

[0019] The domain service is used to encapsulate multi-object logic.

[0020] In some embodiments of the present invention, in the step of using the native business model to encapsulate entity-independent stateless computing logic, a native business model is created and all native business model behaviors are defined, and data verification logic and stateless business logic are implemented through the native business model.

[0021] In some embodiments of the present invention, the step of using the entity to encapsulate the stateful behavior of a single object includes:

[0022] Create a new domain object with an ID as an entity;

[0023] The newly created object storage interface is responsible for the storage and reading of entities. The object storage interface implements database storage, in which the data class is used as the connection between the DAO operation of the database type and the entity.

[0024] In some embodiments of the present invention, in the step of creating a new object storage interface responsible for storing and reading entities and implementing the object storage interface to complete database storage, an object storage interface class AccountRepository and its implementation class AccountRepositoryImpl are created: in the implementation class, account query and account saving are implemented based on the injection of the database operation class AccountMapper and the entity class generator AccountBuilder, wherein the account data object AccountDTO is used as the carrier object of database data, and then converted into an Account entity through AccountBuilder.

[0025] In some embodiments of the present invention, in the step where the anti-corrosion layer receives data from an external system and converts the data into a format applicable to the domain layer, the anti-corrosion layer defines a unified interface and data model for interacting with external services.

[0026] The second aspect of the present invention also provides a financial domain code architecture design system based on domain-driven design, the system comprising a computer device, the computer device comprising a processor and a memory, the memory storing computer instructions, the processor being used to execute the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the system implements the steps implemented by the method described above.

[0027] The third aspect of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps implemented by the aforementioned financial domain code architecture design method based on domain-driven design.

[0028] Additional advantages, purposes, and features of the present invention will be described in part in the following description, and will become apparent to those skilled in the art after studying the following, or may be learned from the practice of the present invention. The purposes and other advantages of the present invention may be specifically pointed out and obtained in the specification and the accompanying drawings.

[0029] Those skilled in the art will appreciate that the objectives and advantages that can be achieved with the present invention are not limited to the above specific description, and the above and other objectives that can be achieved by the present invention will be more clearly understood from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of this application, and do not constitute a limitation of the present invention.

[0031] Figure 1 A schematic diagram of an implementation of a method for designing a code architecture in the financial field based on domain-driven design according to the present invention;

[0032] Figure 2 This is a schematic diagram of the architecture of the financial field code architecture design method based on domain-driven design of the present invention. DETAILED DESCRIPTION

[0033] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments and the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0034] It should also be noted that, in order to avoid obscuring the present invention due to unnecessary details, only structures and / or processing steps closely related to the solutions according to the present invention are shown in the accompanying drawings, while other details that are not closely related to the present invention are omitted.

[0035] Domain-Driven Design: DDD (Domain-Driven Design), also known as "the way to deal with software core complexity", is a software development method for dealing with complex systems. It emphasizes design and development centered on business domain knowledge, and is closely linked to the evolution of core business concepts through software implementation. DDD is suitable for business systems that are productized, continuously iterated, and have sufficiently complex business logic.

[0036] Code architecture design: Code architecture design is a key task in the software development process. It involves determining the high-level structure and component division of the system and clarifying the interaction between components. Good architecture design can improve the maintainability, scalability and reliability of the code.

[0037] Anemic model: When defining an object, the anemic model specifies the attribute information of the object, but does not have the behavior information of the object. All business logic is placed in the so-called business layer (xxxService, xxxManager objects), and these models are needed to transfer data.

[0038] Hyperemic model: When defining an object, the hyperemic model includes not only the attribute information of the object, but also the behavior information of the object. Therefore, the hyperemic model is a model with behavior. The change of state in the model can only be triggered by the behavior on the model. At the same time, all constraints and business logic are converged on the model.

[0039] In the existing technology, the most similar is the traditional three-tier architecture design, which is designed with high cohesion and low coupling. Through layered design, the system is more modular, easy to maintain and expand. It divides the application into three core parts:

[0040] Presentation layer (UI): responsible for providing users with an interactive operation interface, data input and output, accepting user requests and displaying processing results. It is the direct window for users to interact with the system.

[0041] Business Logic Layer (BLL): Receives data from the presentation layer, performs logical judgment and processing, calls the data access layer according to requirements, and returns the processing results to the presentation layer. It is the main implementation part of the system business rules.

[0042] Data Access Layer (DAL): Responsible for operating the database, including adding, deleting, modifying and querying data, and returning the operation results to the business logic layer. It is the bridge for the system to interact with the database.

[0043] The disadvantages of the existing technology include:

[0044] Most of the codes are transaction scripts and the objects are anemic models, which will lead to poor code maintainability, poor scalability and poor testability in the long run.

[0045] 1. Poor maintainability

[0046] (1) Instability of data structure: Business logic is strongly coupled with data objects. When the data structure changes frequently, the corresponding business logic will also be directly affected.

[0047] (2) Instability of third-party service dependencies: The business logic is strongly coupled with the third-party service operation class. When the third-party service dependency, API, or usage method changes, the corresponding business logic will also be directly affected.

[0048] 2. Poor scalability

[0049] (1) Business logic cannot be reused: Each use case has its own special logic, and incompatible data formats will result in the core business logic being unable to be reused, which will ultimately lead to increasingly poor scalability.

[0050] 3. Poor testability

[0051] (1) Difficulty in setting up facilities: The code is highly dependent on external dependencies such as databases, third-party services, and middleware. Due to the instability of various systems, it is very difficult to run a complete test case.

[0052] (2) Long runtime: Most external dependency calls are I / O intensive, such as cross-network calls and disk calls, and such I / O calls take a long time during testing. The long startup time of the Spring container will also indirectly increase the test time.

[0053] (3) High coupling: When multiple sub-steps in a script are highly coupled, the number of test cases required for complete coverage may increase exponentially, resulting in huge testing costs.

[0054] like Figure 1 and 2 As shown, the present invention proposes a financial field code architecture design method based on domain-driven design, the method comprising step S100, user interface layer design, step S200, infrastructure layer design, step S300, domain layer design and step S400, application layer design;

[0055] In the step of user interface layer design, a user interface layer for interacting with a user is constructed, wherein the user interface layer receives user input and feeds back processing results to the user;

[0056] In the step of infrastructure layer design, an infrastructure layer for providing underlying resource services is constructed, wherein the infrastructure layer provides a database or a message middleware;

[0057] In the step of domain layer design, entities, native business models and domain services in the domain layer are constructed;

[0058] In the application layer design step, an application layer is constructed for interaction between the domain layer and the user interface layer. The application layer calls domain layer services or external microservices. The application layer also includes an anti-corrosion layer, which receives data from external systems and converts it into a format suitable for the domain layer.

[0059] In the specific implementation process, the main goal of the anti-corrosion layer ACL is to ensure that changes in one system do not directly affect other systems. It acts as a buffer layer to filter or transform data and requests to keep the system clean and consistent. By using the anti-corrosion layer, the complexity and irregularities of external systems can be limited to this layer to prevent them from penetrating into the core area. When external dependencies change, only adjustments need to be made in the anti-corrosion layer instead of modifications in the entire system, which reduces maintenance costs and improves system stability and maintainability.

[0060] By adopting the above solution, this solution sinks the non-core business concepts, rules and verifications of data objects (Data Object) into the native business model (Domain Primitive), decouples from the data storage layer through the object storage interface class (Repository), adds an anti-corrosion layer (ACL) to the third-party service, abstracts the entity class (Entity) with data and behavior, combines and orchestrates application services through the application layer (Application Service), adapts to changes in business processes, calls domain layer services or external microservices, completes business logic, and ultimately improves the maintainability, scalability and testability of the code.

[0061] In some embodiments of the present invention, the user interface layer is used to process RESTful requests, parse configuration information, and pass it to the application layer.

[0062] In the specific implementation process, the User Interface Layer is responsible for interacting with users, receiving user input and displaying processing results. The User Interface Layer processes RESTful requests, parses configuration information, and passes data assembly to the application layer.

[0063] In the specific implementation process, RESTful (Representational State Transfer) is a design style and development method for network applications, which relies on the HTTP protocol, especially the statelessness of HTTP and the unified interface for resources. RESTful requests refer to HTTP requests that follow the REST principles.

[0064] The core principles of RESTful requests include:

[0065] Resources: In the RESTful architecture, all content is considered as resources, such as users, orders, products, etc. Each resource is uniquely identified by a URI (Uniform Resource Identifier), for example, / users / 123 represents the user with ID 123.

[0066] Statelessness: Each request is independent and the server does not save any client state between requests. The client needs to include all necessary information, such as authentication tokens, with each request.

[0067] Standardized HTTP methods: RESTful API uses HTTP methods to perform operations, including GET, POST, PUT, DELETE, and PATCH. Each method has its specific meaning and purpose, such as GET is used to retrieve resources, POST is used to create resources, PUT is used to update resources, DELETE is used to delete resources, and PATCH is used to partially update resources.

[0068] Representation: Resources can have multiple representations, such as JSON, XML, and HTML. The client can specify the resource representation it wants to obtain through the Accept field in the HTTP request header.

[0069] In some embodiments of the present invention, in the process of the application layer calling the domain layer service or the external microservice, the application layer calls the corresponding domain layer service or the external microservice based on the business processing flow to complete the corresponding data processing.

[0070] For example:

[0071] Create the Application Service class TransferService and its implementation class TransferServiceImpl for the transfer business function: In the implementation class, inject dependencies into the object storage interface class AccountRepository, the exchange rate conversion class ExchangeRateService, and the transfer function class AccountTransferService. Implement the core business logic by combining and arranging the relevant methods of the domain layer and the data storage layer.

[0072] Implement the Domain Layer: Implement the core business logic through Entity, DP and Domain Service, encapsulate business concepts, rules and validation. Includes domain objects such as aggregate roots, entities, and value objects.

[0073] 1. Use DP to encapsulate stateless computing logic that is independent of the entity.

[0074] 2. Use Entity to encapsulate the stateful behavior of a single object, including business verification.

[0075] 3. Use Domain Service to encapsulate multi-object logic.

[0076] For example:

[0077] Create the Domain Service class AccountTransferService and its implementation class AccountTransferServiceImpl for the transfer function: In the implementation class, inject the exchange rate conversion class ExchangeRateService into the dependency. Implement the transfer method by encapsulating the exchange rate conversion method of ExchangeRate and the deposit and withdraw methods of Account.

[0078] In some embodiments of the present invention, in the step of constructing entities, native business models and domain services in the domain layer:

[0079] The entity is used to encapsulate the stateful behavior of a single object, including business verification;

[0080] The native business model is used to encapsulate stateless computing logic that is independent of the entity;

[0081] The domain service is used to encapsulate multi-object logic.

[0082] In the specific implementation process, entity is a domain concept that needs to be uniquely identified in the domain. In business logic, entity represents the data and operations of the business domain, usually mapped to a table in the database. Entity has an ID, and its fields are not necessarily related to database storage. It contains not only data but also behavior. For example, in the ABP framework, all entity classes inherit from Entity, and Entity implements the IEntity interface;

[0083] Domain Primitive (DP): Encapsulates stateless computing logic that is independent of entities. DP is a Value Object that has precise definitions, self-verification, and behavior in a specific domain, and has the feature of Immutable. The three principles of using DP are: making implicit concepts explicit, making implicit contexts explicit, and encapsulating multi-object behaviors;

[0084] Domain Service: Use Domain Service to encapsulate multi-object logic.

[0085] In some embodiments of the present invention, in the step of using the native business model to encapsulate entity-independent stateless computing logic, a native business model is created and all native business model behaviors are defined, and data verification logic and stateless business logic are implemented through the native business model.

[0086] In the process of creating the native business model (Domain Primitive, DP for short), define all DP behaviors. Implement data verification logic and stateless business logic through DP.

[0087] For example:

[0088] 1. Create an account id class AccountId: a private account id attribute, and add id-related verification logic to the public construction method.

[0089] 2. Create an account number class AccountNumber: private account number attribute, and add number-related verification logic to the public construction method.

[0090] 3. Create a user id class UserId: private user id attribute, and add id-related verification logic to the public construction method.

[0091] 4. Create the amount class Money: private amount and exchange rate attributes, and add relevant verification logic for the amount and exchange rate in the public construction method.

[0092] In some embodiments of the present invention, the step of using the entity to encapsulate the stateful behavior of a single object includes:

[0093] Create a new domain object with an ID as an entity;

[0094] The newly created object storage interface is responsible for the storage and reading of entities. The object storage interface implements database storage, in which the data class is used as the connection between the DAO operation of the database type and the entity.

[0095] Create a new entity class (Entity): Entity is a domain object with an ID. In addition to data, it also has behavior. Entity has nothing to do with the database storage format. The design should be based on the universal language of the field.

[0096] For example:

[0097] Create an account entity class Account: Use the created DP class as attributes, including private account id (AccountId), account number (AccountNumber), user id (UserId), available amount (Money), current limit (Money), etc. Add entity class behaviors, including getting exchange rate (getCurrency), deposit (deposit), withdraw (withdraw), etc., which contain relevant verification and corresponding business logic.

[0098] Create a new object storage interface class (Repository): responsible for the storage and reading of Entity objects. The implementation class of Repository completes the details of database storage, and the data class (Data Object) serves as a bridge between DAO (database type operation) and Entity. By adding the Repository interface, the underlying database connection can be replaced by different implementation classes.

[0099] For example:

[0100] Create the object storage interface class AccountRepository and its implementation class AccountRepositoryImpl: In the implementation class, inject the database operation class AccountMapper and the entity class generator AccountBuilder. Implement methods such as account query and account saving, where the account data object AccountDTO is used as the carrier object of database data, and then converted to Account entity through AccountBuilder.

[0101] In some embodiments of the present invention, in the step of creating a new object storage interface responsible for storing and reading entities and implementing the object storage interface to complete database storage, an object storage interface class AccountRepository and its implementation class AccountRepositoryImpl are created: in the implementation class, account query and account saving are implemented based on the injection of the database operation class AccountMapper and the entity class generator AccountBuilder, wherein the account data object AccountDTO is used as the carrier object of database data, and then converted into an Account entity through AccountBuilder.

[0102] In some embodiments of the present invention, in the step where the anti-corrosion layer receives data from an external system and converts the data into a format applicable to the domain layer, the anti-corrosion layer defines a unified interface and data model for interacting with external services.

[0103] With the above solution, the anti-corrosion layer ACL solves the problem of strong coupling between input and output parameters, including:

[0104] Define the uniform interface:

[0105] In the anti-corrosion layer ACL, a unified set of interfaces and data models can be defined for interacting with external services.

[0106] These interfaces and data models can be customized according to the needs of the system to ensure that they are consistent with the internal logic of the system.

[0107] Implementing the Adapter pattern:

[0108] The adapter pattern is a commonly used design pattern used to convert one interface to another.

[0109] In the anti-corrosion layer ACL, an adapter can be implemented to convert the API and data structure of the external service into a form that can be understood and processed by the internal system.

[0110] This way, even if the API and data structure of the external service changes, the adapter can be adjusted accordingly without making large-scale modifications to the internal logic of the system.

[0111] Reduce coupling:

[0112] By introducing the anti-corrosion layer ACL and adapter mode, the coupling between the system and external services can be reduced to a minimum.

[0113] In this way, the system can respond more flexibly to changes in external services and reduce system risks caused by changes in external services.

[0114] The anti-corrosion layer ACL solves the problem of uncontrollable third-party services and strong coupling of input and output parameters in an abstract way. It reduces the coupling between systems by isolating external dependencies from internal logic and defining unified interfaces and data models. At the same time, by implementing the adapter pattern to convert the API and data structure of external services, the system can respond to changes in external services more flexibly. These features make the anti-corrosion layer ACL one of the important tools for building maintainable and scalable software systems.

[0115] For example:

[0116] Create the exchange rate conversion class ExchangeRateService and its implementation class ExchangeRateServiceImpl: In the implementation class, inject the third-party exchange rate tool class YahooForexService into the dependency. Implement methods such as obtaining exchange rates, encapsulate corresponding third-party operations, and decouple the business layer from third-party services.

[0117] In summary, this solution uses DDD for code architecture design, and adopts a congestion model for objects to reduce the coupling between object behavior and the service layer, ultimately improving the maintainability, scalability, and testability of the code.

[0118] The beneficial effects of this program include:

[0119] 1. High maintainability: When external dependencies change, the internal code only needs to change the module that connects to the external system, and other business logic remains unchanged.

[0120] 2. High scalability: When developing new features, most of the code can be reused, and only the core business logic needs to be added.

[0121] 3. High testability: Each split module complies with the principle of unity, most of them do not rely on the framework, and can be quickly unit tested to achieve 100% coverage.

[0122] 4. Clear code structure: The POM module can be used to resolve dependencies between modules, and all external modules can be reused as separate Jar packages. Once the team forms a standard, it can quickly locate the relevant code.

[0123] An embodiment of the present invention also provides a financial domain code architecture design system based on domain-driven design, the system comprising a computer device, the computer device comprising a processor and a memory, the memory storing computer instructions, the processor being used to execute the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the system implements the steps implemented by the method described above.

[0124] The embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps implemented by the aforementioned financial domain code architecture design method based on domain-driven design are implemented. The computer-readable storage medium can be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0125] It should be understood by those skilled in the art that the exemplary components, systems and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software or a combination of the two. Whether it is 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. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0126] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0127] In the present invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with features of other embodiments or replace features of other embodiments.

[0128] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A financial code architecture design method based on domain-driven design, characterized in that: The steps of the method include user interface layer design, infrastructure layer design, domain layer design, and application layer design; In the step of user interface layer design, a user interface layer for interacting with a user is constructed, wherein the user interface layer receives user input and feeds back processing results to the user; In the step of infrastructure layer design, an infrastructure layer for providing underlying resource services is constructed, wherein the infrastructure layer provides a database or a message middleware; In the step of domain layer design, entities, native business models and domain services in the domain layer are constructed; In the application layer design step, an application layer is constructed for interaction between the domain layer and the user interface layer. The application layer calls domain layer services or external microservices. The application layer also includes an anti-corrosion layer, which receives data from external systems and converts it into a format suitable for the domain layer.

2. The financial domain code architecture design method based on domain-driven design according to claim 1 is characterized in that: The user interface layer is used to process RESTful requests, parse configuration information, and pass it to the application layer.

3. The financial domain code architecture design method based on domain-driven design according to claim 1 is characterized in that: In the process of the application layer calling the domain layer service or the external microservice, the application layer calls the corresponding domain layer service or the external microservice based on the business processing flow to complete the corresponding data processing.

4. The financial domain code architecture design method based on domain-driven design according to claim 1 is characterized in that: In the steps of building entities, native business models, and domain services in the domain layer: The entity is used to encapsulate the stateful behavior of a single object, including business verification; The native business model is used to encapsulate stateless computing logic that is independent of the entity; The domain service is used to encapsulate multi-object logic.

5. The financial domain code architecture design method based on domain-driven design according to claim 4 is characterized in that: In the step of using the native business model to encapsulate entity-independent stateless computing logic, a native business model is created, and all native business model behaviors are defined, and data verification logic and stateless business logic are implemented through the native business model.

6. The financial domain code architecture design method based on domain-driven design according to claim 4 is characterized in that: The steps of using the entity to encapsulate the stateful behavior of a single object include: Create a new domain object with an ID as an entity; The newly created object storage interface is responsible for the storage and reading of entities. The object storage interface implements database storage, in which the data class is used as the connection between the DAO operation of the database type and the entity.

7. The method for designing a financial domain code architecture based on domain-driven design according to claim 6, characterized in that: In the step of creating a new object storage interface responsible for storing and reading entities and implementing the object storage interface to complete database storage, create the object storage interface class AccountRepository and its implementation class AccountRepositoryImpl: In the implementation class, based on the injection of the database operation class AccountMapper and the entity class generator AccountBuilder, account query and account saving are implemented, where the account data object AccountDTO is used as the carrier object of database data, and then converted to an Account entity through AccountBuilder.

8. The financial domain code architecture design method based on domain-driven design according to claim 1 is characterized in that: In the step where the anti-corrosion layer receives data from an external system and converts the data into a format suitable for the domain layer, the anti-corrosion layer defines a set of unified interfaces and data models for interacting with external services.

9. A financial domain code architecture design system based on domain-driven design, characterized in that: The system includes a computer device, which includes a processor and a memory. The memory stores computer instructions. The processor is used to execute the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the steps implemented by the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the steps implemented by the method as claimed in any one of claims 1 to 8 are implemented.

Images