CN112882689B

CN112882689B - Engineering architecture method based on domain-driven design and detailed design framework

Info

Publication number: CN112882689B
Application number: CN202110097920.XA
Authority: CN
Inventors: 宋松涛; 宋秀庆
Original assignee: Zhongyuan Bank Co ltd
Current assignee: Zhongyuan Bank Co ltd
Priority date: 2021-01-25
Filing date: 2021-01-25
Publication date: 2022-05-20
Anticipated expiration: 2041-01-25
Also published as: CN112882689A

Abstract

The disclosure relates to an engineering architecture method and a detailed design framework based on domain-driven design, wherein the engineering architecture method comprises the following steps: the method comprises the steps that a method based on field driving is adopted to carry out layering on an engineering architecture, wherein the layering comprises an application service layer, a field aggregation layer and a technology adaptation layer, the application service layer is used for realizing application services, including service arrangement, parameter verification, model assembly and the like, the field aggregation layer is used for realizing core business logic in a field, including a field model, field services and the like, and the technology adaptation layer is used for realizing interfaces or abstract classes in the field aggregation layer and realizing related data access; and constraining the dependency relationship among the application service layer, the field aggregation layer and the technology adaptation layer, wherein the application service layer depends on the field aggregation layer, the technology adaptation layer depends on the field aggregation layer, the field aggregation layer does not depend on other layers, and the application service layer and the technology adaptation layer are independent of each other.

Description

Engineering architecture method based on domain-driven design and detailed design framework

Technical Field

The disclosure belongs to the field of application software program development, and relates to software engineering and software architecture design and development in software development, in particular to an engineering architecture method and a detailed design framework based on field-driven design.

Background

The domain-driven design is a design idea for processing a highly complex domain, attempts to separate the complexity of technical implementation, and constructs a domain model around a business concept to control the complexity of business so as to solve the problems of difficulty in understanding and evolution of software and the like. The existing field-driven design is mainly used for solving the problem that software complexity is higher and higher in front-end application program development, but a general non-front-end layering method and a landing mode of general field-driven design engineering cannot be provided, and particularly, all technologies and service separation are not restricted at an architecture level, so that a development mode of mixed development of services and technologies of general developers cannot be avoided.

Disclosure of Invention

The present disclosure is provided to solve the above-mentioned problems occurring in the prior art.

An engineering architecture method and a detailed design framework based on domain-driven design are needed, a reasonable layering method and a detailed design framework can be provided for engineering design and development based on the domain-driven method, technology and service are better separated, service evolution and code reconstruction are facilitated, and engineering design development efficiency is provided at the same time.

According to a first aspect of the present disclosure, an engineering architecture method based on a domain-driven design is provided, where the engineering architecture method may include layering an engineering architecture by a domain-driven-based method, where the layering includes an application service layer, a domain aggregation layer, and a technology adaptation layer, where the application service layer is used for implementation of application services including service arrangement, parameter verification, model assembly, and the like, the domain aggregation layer is used for implementation of core business logic in a domain including a domain model, a domain service, and the technology adaptation layer is used for implementation of interfaces or abstract classes in the domain aggregation layer, and implementation related to data access. The engineering architecture method further comprises the step of constraining the dependency relationship among the application service layer, the domain aggregation layer and the technology adaptation layer, wherein the application service layer depends on the domain aggregation layer, the technology adaptation layer depends on the domain aggregation layer, the domain aggregation layer does not depend on other layers, and the application service layer and the technology adaptation layer are independent of each other.

According to a second scheme of the disclosure, a detailed design framework of an engineering architecture based on a domain-driven design is provided, wherein the detailed design framework comprises an application service layer, a domain aggregation layer and a technology adaptation layer, and the application service layer, the domain aggregation layer and the technology adaptation layer are designed in detail according to directory structure constraints.

By using the engineering architecture method and the detailed design framework of the engineering architecture according to the embodiments of the present disclosure, on the basis of a hierarchical design, by constraining the dependency relationship between layers, the separation of applications, services and technologies is effectively achieved, the field model is better focused and guarded, and the detailed design framework of the engineering architecture is used for design and development, so that the cost of a developer for learning the field-driven design code structure can be significantly reduced, and the engineering code can be strongly constrained, thereby ensuring the standardization of the engineering code, improving the engineering design and development efficiency, and providing convenience for service evolution and code reconstruction.

Drawings

In the drawings, which are not necessarily drawn to scale, like reference numerals may describe similar parts throughout the different views. The drawings illustrate various embodiments generally by way of example and not by way of limitation, and together with the description and claims serve to explain the disclosed embodiments. The same reference numbers will be used throughout the drawings to refer to the same or like parts, where appropriate. Such embodiments are illustrative, and are not intended to be exhaustive or exclusive embodiments of the present apparatus or method.

FIG. 1 shows a schematic diagram of the hierarchy of an engineering architecture method and dependencies between layers according to an embodiment of the present disclosure;

FIG. 2 illustrates a directory structure schematic diagram of an application service layer in a detailing framework according to an embodiment of the disclosure;

FIG. 3 illustrates a directory structure representative diagram of a domain aggregation layer in a detailing framework according to an embodiment of the disclosure;

FIG. 4 illustrates a directory structure schematic diagram of a technology adaptation layer in a detailing framework according to an embodiment of the disclosure.

Detailed Description

For those skilled in the art to better understand the technical solutions of the present disclosure, the following detailed description of the present disclosure is provided in conjunction with the accompanying drawings and specific embodiments.

It should be understood that various modifications may be made to the embodiments of the present disclosure. Accordingly, the foregoing description should not be construed as limiting, but merely as exemplifications of embodiments. Other modifications will occur to those skilled in the art within the scope and spirit of the disclosure.

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the disclosure and, together with a general description of the disclosure given above, and the detailed description of the embodiments given below, serve to explain the principles of the disclosure.

These and other characteristics of the present disclosure will become apparent from the following description of preferred forms of embodiment, given as non-limiting examples, with reference to the attached drawings.

It should also be understood that although the present disclosure has been described with reference to some specific examples, those skilled in the art can certainly realize many other equivalent forms of the present disclosure.

The above and other aspects, features and advantages of the present disclosure will become more apparent in view of the following detailed description when taken in conjunction with the accompanying drawings.

Specific embodiments of the present disclosure are described hereinafter with reference to the accompanying drawings; however, it is to be understood that the disclosed embodiments are merely exemplary of the disclosure that may be embodied in various forms. Well-known and/or repeated functions and structures have not been described in detail so as not to obscure the present disclosure with unnecessary or unnecessary detail. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present disclosure in virtually any appropriately detailed structure.

The specification may use the phrases "in one embodiment," "in another embodiment," "in yet another embodiment," or "in other embodiments," which may each refer to one or more of the same or different embodiments in accordance with the disclosure.

Fig. 1 shows a schematic diagram of the hierarchy and dependencies between layers of an engineering architecture method according to an embodiment of the present disclosure. In the engineering architecture method according to the embodiment of the present disclosure, a domain-driven-based method is adopted to layer an engineering architecture, and in a layered structure, as shown in fig. 1, an application service layer 11, a domain aggregation layer 12, and a technology adaptation layer 13 may be included.

The application service layer 11 is used for implementing application services, including service arrangement, parameter verification, model assembly, and the like.

The service arrangement is a complete business process for organizing and cooperating the work of the independent components and the application layer in the application service, relates to inter-process communication modes, distributed transactions and the like, and is supported by designing a complete arrangement framework. In some embodiments, the inter-process communication mode may be implemented by using an rpc (Remote Procedure call) framework, for example, based on a Java Remote Method Protocol (Java Remote Protocol) using a Java. In other embodiments, distributed transactions may be processed through, for example, the two-Phase commit Protocol (2Phase commit Protocol). In other embodiments, different frameworks such as executable-oriented flow, collaboration-oriented or API gateway may be used to implement service orchestration.

The parameter verification in the application service refers to verifying the input of a user at the front end and the background of the service so as to ensure the correctness of the system data. In some embodiments, the parameter check may be performed, for example, using JSR303, a JavaBean parameter check standard.

The model assembly in the application service refers to an operation of assembling a plurality of service models created in the application service layer to form a new service model.

The domain aggregation layer 12 is used for implementing core business logic in the domain, including domain models, domain services, and the like. The domain model in the domain aggregation layer 12 is also referred to as a business object model, is a visual representation of concept classes in the domain or objects in the real world, and is established by analyzing the problem domain, exploring important business domain concepts, defining business cases from the viewpoint inside the business role, and establishing relationships between the business domain concepts. In some embodiments, the domain model also defines the roles that business personnel assume in the business and their current responsibilities, as well as the static and dynamic relationships that they have between objects processed and used, in order to produce the desired effect. All the business object models are combined together, and all the business use cases can be executed.

In some embodiments, the domain services in the domain aggregation layer 12 represent stateless operations that implement tasks for a domain, and operations in the domain services, from a domain perspective, are a whole. "recommending financial products to bank customers" may be considered as one specific example of a domain service.

The technology adaptation layer 13 is used for implementation of interfaces or abstract classes in the domain aggregation layer 12, and data access related implementations.

In the engineering architecture method according to the present embodiment, the domain aggregation layer 12 is used as a core, and the dependency relationship between the layers is defined. First, in some embodiments, the constraint application service layer 11 relies on the domain aggregation layer 12, while the domain aggregation layer 12 does not rely on the application service layer 11. Namely: in the modules and codes specifically implemented by the application service layer 11, the modules and codes in the domain aggregation layer 12 may be directly called, and the modules and codes in the domain aggregation layer 12 are not allowed to directly call any modules and codes in the application service layer 11 according to the dependency relationship defined by the embodiment of the present disclosure.

In other embodiments, it is also constrained that the technology adaptation layer 13 depends on the domain aggregation layer 12, while the domain aggregation layer 12 does not depend on the application service layer 11, and the application service layer 11 and the technology adaptation layer 13 are independent of each other. Namely: among the modules and codes of the technology adaptation layer 13, the modules and codes in the domain aggregation layer 12 are allowed to be directly called, while the modules and codes in the domain aggregation layer 12 are not allowed to be directly called, and the modules and codes of the technology adaptation layer 13 and the modules and codes of the application service layer 11 are not directly called each other.

As an example, when a micro-service is constructed by adopting maven engineering, the micro-service performs engineering design based on domain-driven design according to the embodiment of the present disclosure, where a parent engineering is a micro-service, and includes a plurality of functional modules, each functional module is implemented by a sub-engineering, and each functional module belongs to one of the application service layer 11, the domain aggregation layer 12, and the technology adaptation layer 13. During engineering design, firstly, modeling of a business core concept is performed according to a business model to generate a domain model, and a functional module developed according to the domain model belongs to a domain aggregation layer 12. It can be understood that, when the engineering architecture method based on the domain-driven design in the embodiment of the present disclosure is used for engineering design, the domain aggregation layer 12 is designed and developed before other layers, so that the design is not dependent on other layers, and the module and code implementation thereof also does not allow to invoke any content in other application service layers 11 or technology adaptation layers 13. In other embodiments, the dependencies of the modules or codes in the constraint technology adaptation layer 13 for implementing the interface or abstract class in the domain aggregation layer 12 and the data access related implementation are adapted, that is: only modules and code in the domain aggregation layer 12 are allowed to be called, and modules and code in the application service layer 11 are not allowed to be directly called to realize the dependency relationship thereof as shown in fig. 2. Similarly, the application service layer 11 only allows the modules and codes in the domain aggregation layer 12 to be called when implementing functions including the orchestration of services, parameter verification, model assembly, etc., but does not allow any contents in the technology adaptation layer 13 to be directly called. Therefore, the dependency constraint between the layers in the embodiment of the present disclosure is realized through the dependency constraint represented by the calling relationship between the modules.

In some embodiments, the application service layer 11 may also interact with the open host access layer 14 through an appropriate interface to collectively implement application service functions.

In some embodiments, the technical adaptation layer 13 may also interact with the infrastructure layer 15 as a platform support through a suitable interface to provide the technical support and service capabilities required by the project.

In other embodiments, there is a bonder 16 for data conversion and transfer between layers in different formats.

Fig. 2 to 4 respectively show directory structure diagrams of an application service layer, a domain aggregation layer, and a technology adaptation layer of a detailed design framework according to an embodiment of the present disclosure. In an embodiment according to the second aspect of the present disclosure, a customized engineering directory structure developed based on Eclipse plug-ins may be adopted to implement constraints on the directory structures of the respective layers. In other embodiments, the above directory structure may also be implemented using the IntelliJ Idea plug-in.

As shown in fig. 2, the application service layer directory structure 21 illustratively includes subdirectories: API accessor (internal) 211, API accessor (external) 212, and application services 213. Wherein the content of the first and second substances,

API accessor (internal) 211 is an entry directory for micro-service internal access application services configured to further include:

accessor 2111 may be configured to: a package for hosting an implementation of an application service portal; and

the transport object 2112 may be configured to: an object for transferring data between different design modes.

API accessor transport object (external) 212 is an entry directory for a microservice external access application service that is configured to further include:

the application service 213 may be configured to: a collection catalog of services that does not contain domain knowledge, the catalog further configured to include:

common definition 2131 may be configured to: the package is used for storing tool classes and constant definitions;

service interface 2133 may be configured to: a package for storing service interfaces; and

service development 2134 may be configured to: the package of service implementation is stored.

Fig. 3 illustrates a directory structure diagram of a domain aggregation layer according to an embodiment of the disclosure. When the engineering architecture method based on the domain-driven design is used for engineering design, the domain aggregation layer 12 does not depend on other layers, performs design development before other layers, is the core of the whole engineering design, and is simultaneously depended on by the application service layer 11 and the technology adaptation layer 13 in the subsequent system operation, that is: the module and the code of the method are called by the codes in the application service layer 11 and the technology adaptation layer 13, so that the standardization of the directory structure of the domain aggregation layer can not only improve the modeling efficiency of the domain model, but also enable the development of the application service layer 11 and the technology adaptation layer 13 depending on the layer to be more efficient and easy to maintain.

As shown in fig. 3, the directory structure 31 of the domain aggregation layer illustratively includes subdirectories: read model 311, domain service 312, common definition 313, adapter 314, domain aggregation 315, and example aggregation 316. Wherein the content of the first and second substances,

the read model 311 is used for solving a scheme of associating complex queries across multiple aggregation multiple tables in a domain-driven design mode, and is configured to further include:

the read service 3111 may be configured to: providing services of the complex query class; and

the warehouse accessor 3112 may be configured to: an interface to access the data model for use by read service 3111;

the domain service 312 may be configured to: services that contain domain knowledge, which is a series of stateless operations that enrich the domain's proprietary tasks and perform meaningful business processes, may be services that cross multiple aggregate knowledge in some embodiments;

the common definition 313 may be configured to: the package is used for storing tool classes and constant definitions;

the adapter 314 is an adaptation tool for some external systems or technical implementations which need to be accessed in the field, and here, an interface is stored, and the specific implementation can be configured in a technical adaptation layer to further include:

the service schedule 3141 may be configured to: implementing a call to another microservice;

the flow schedule 3142 may be configured to: calling the flow arrangement is realized;

the message schedule 3143 may be configured to: realizing the sending or receiving of messages; and

distributed schedule 3144 may be configured to: and realizing a timing task.

The domain aggregation layer 12 may comprise at least one domain aggregation, two of which, domain aggregation a and domain aggregation B, are shown in fig. 3 by way of example only. Each of the plurality of domain aggregations having similar contents contained in the directory, for example, the domain aggregation a may further include:

domain service a1 may be configured to: domain services within an aggregation, focusing on domain knowledge within an aggregation;

transport object a2 may be configured to: objects for data transfer between layers;

constant definition a3 may be configured as: packets defining some constant, or error code;

the domain model a4 may be configured to: and storing a package of the domain model, wherein the domain model is a business area covered by engineering design, and the problem in the domain is solved according to business requirements by using terms and languages commonly used in the industry.

Polymerization plant a5 may be configured to: implementing a package created by aggregation initialization; and

the warehouse accessor a6 may be configured to: and an interface for realizing aggregation persistence and acquisition.

The domain polymerization B, as another domain polymerization example in the domain polymerization layer 12, may have the same or similar configuration as the domain polymerization a, or may have a different configuration.

Fig. 4 illustrates a directory structure diagram of a technology adaptation layer according to an embodiment of the present disclosure.

As shown in fig. 4, the directory structure 41 of the technology adaptation layer illustratively includes subdirectories: data repository 411, read model 412, adapter 413, domain service 414, domain aggregate 415, and example aggregate 416. Wherein the content of the first and second substances,

the repository 411 may be configured to store a directory of related files for accessing the database, which further includes an accessor (Mybatis)4111, which is a directory implemented for Mybatis to access the database, having a Mapper 4111a as a Mapper interface in Mybatis, a data Model 4111b in Mybatis, and an XML file XML 4111c in Mybatis.

The read model 412 may be configured to: and aiming at the specific implementation catalog of the interface of the read model in the domain aggregation module.

The adapter 413 may be configured to: the specific implementation catalog for the adapter interface in the domain aggregation module further comprises:

the service schedule 4131 may be configured to: specific implementation of a service scheduling interface in a domain aggregation module;

the flow schedule 4132 may be configured to: specific implementation of a process scheduling interface in a domain aggregation module;

the message schedule 4133 may be configured to: aiming at the specific realization of a message scheduling interface in a domain aggregation module;

the distributed schedule 4134 may be configured to: the method is specific to the implementation of a distributed scheduling interface in a domain aggregation module.

Domain service 414 may be configured to: specific implementation for abstractions in a domain service in a domain aggregation module;

the domain aggregation AA can be configured as: the directory of interface implementations for corresponding domain aggregations a in the domain aggregation layer 12 may further include a repository accessor AA6 configured as a concrete implementation for an interface of a repository accessor a6 in a particular domain aggregation a in the domain aggregation layer 12.

A domain aggregation BB configured as a directory of interface implementations of the domain aggregation B in the domain aggregation layer 12.

In this embodiment, the detailed design framework is consistent with the hierarchical method in the embodiment according to the first aspect of the present disclosure, and the directory structure of each layer is strongly constrained, so that not only can the normalization of the code be improved, but also the cost for driving the design of the code structure in the field of developer learning can be significantly reduced, and the efficiency of system design and development can be improved.

The above description is intended to be illustrative and not restrictive. For example, the above-described examples (or one or more versions thereof) may be used in combination with each other. For example, other embodiments may be used by those of ordinary skill in the art upon reading the above description. In addition, in the foregoing detailed description, various features may be grouped together to streamline the disclosure. This should not be interpreted as an intention that a disclosed feature not claimed is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the detailed description as examples or embodiments, with each claim standing on its own as a separate embodiment.

Claims

1. An engineering architecture method based on a domain-driven design is characterized by comprising the following steps:

the method comprises the steps that a domain-driven-based method is adopted to obtain a hierarchy for an engineering architecture, wherein the hierarchy comprises an application service layer, a domain aggregation layer and a technology adaptation layer, the application service layer is used for realizing application services and at least comprises service arrangement, parameter verification and model assembly, the domain aggregation layer is used for realizing core business logic in a domain and at least comprises a domain model and domain services, and the technology adaptation layer is used for realizing interfaces or abstract classes in the domain aggregation layer and realizing data access correlation;

defining an inter-layer dependency relationship, wherein the inter-layer dependency relationship comprises that the application service layer depends on the domain aggregation layer, the technology adaptation layer depends on the domain aggregation layer, the domain aggregation layer does not depend on other layers, and the application service layer and the technology adaptation layer are not dependent on each other.

2. The engineering architecture method of claim 1, further characterized in that the application service layer interacts with the open host access layer through a communication interface to collectively provide user-oriented application service functionality.

3. The engineering architecture method of claim 1, further characterized in that the technology adaptation layer interacts with an infrastructure layer as a platform support through a communication interface, collectively providing technical support and service capabilities required by the engineering.

4. The engineering architecture method of claim 1, further characterized by having a binder for implementing data conversion and transfer between layers of the application service layer, the domain aggregation layer and the technology adaptation layer.

5. The engineering architecture method of claim 1, further characterized in that the inter-layer dependencies are guaranteed by calling relationship constraints among the codes of the application service layer, the domain aggregation layer, and the technology adaptation layer.

6. A detailed design framework of an engineering architecture based on a domain-driven design, the detailed design framework comprising:

the system comprises an application service layer, a field aggregation layer and a technology adaptation layer, wherein the application service layer is used for realizing application services and at least comprises service arrangement, parameter verification and model assembly; and in the framework of the detailed design,

the directory structure of the application service layer comprises at least one of an API accessor and an application service;

the directory structure of the domain aggregation layer comprises at least one of a reading model, a domain service, a domain model, an aggregation factory, an adapter interface and a warehouse accessor;

the directory structure of the technology adaptation layer comprises at least one of a data warehouse, a reading model, an adapter and a domain service.

7. The detailing framework of claim 6, further characterized in that the directory structure constraints in the detailing framework are implemented using a customized engineering directory structure developed based on Eclipse plug-ins.