DDD (Receive Driven Design) series of common DDD architecture patterns

In the practice of DDD projects, we will use some commonly used architecture patterns to carry out a reasonable design of the system architecture.　

The following are the common architecture patterns of DDD:

• DDD layered architecture

• Neat architecture

• Hexagonal architecture

• DDD layered architecture vs tidy architecture vs hexagonal architecture

• Event Driven architecture

• CQRS(Command Query Responsibility Segregation) 架构

• Domain event design pattern in microservices

• Domain event design pattern between microservices

DDD layered architecture

DDD layered architecture includes user interface layer, application layer, domain layer and basic layer.

An important principle of layered architecture is that each layer can only be coupled with the layer below it .

Layered architecture can be simply divided into two types, namely, strict layered architecture and loose layered architecture . In a strictly layered architecture , a layer can only be coupled with the layer directly below it, while in a loose layered architecture , a layer is allowed to be coupled with any layer below it.

The advantages of layered architecture, Martin Fowler gave the answer in the book "Patterns of Enterprise Application Architecture":

1. Developers can only focus on a certain layer in the entire structure.
2. It is easy to replace the original level of implementation with the new implementation.
3. Can reduce the dependence between layers.
4. Conducive to standardization.
5. Facilitate the reuse of various layers of logic

Appropriate layered architecture isolates the development layers, and these layers are not affected by changes in other layers, making it easier to refactor . Dividing tasks and defining individual layers is the challenge for architects. When the requirements are well adapted to the pattern, these layers will be easy to decouple or develop in layers.

scenes to be used:

• New applications that need to be built quickly
• Applications that require strict maintainability and testability standards

Neat architecture

The tidy architecture is also known as the "onion architecture". The layers of the neat structure are like onion slices, which embodies the layered design idea. In a clean architecture, concentric circles represent different parts of the application software. From the inside to the outside, they are the domain model, domain service, application service, and the outermost content that is easy to change, such as user interface and infrastructure.

The most important principle of a clean architecture is the principle of dependency , which defines the dependency of each layer, the lower the dependency, the higher the code level, the more core competence . The outer circle code dependency can only point to the inner circle, and the inner circle does not need to know anything about the outer circle.

In the onion architecture, the functions of each layer are divided as follows:

• The domain model implements the core business logic in the domain , and it encapsulates the enterprise-level business rules. The main body of the domain model is an entity. An entity can be an object with methods or a collection of data structures and methods.
• Domain service realizes complex business logic involving multiple entities .
• Application services implement service composition and orchestration related to user operations . It contains application-specific business process rules, encapsulates and implements all use cases of the system.
• The outermost layer mainly provides adaptation capabilities, which are divided into active adaptation and passive adaptation. Active adaptation mainly realizes the adaptation of internal business logic access to external users, web pages, batch processing, and automated testing. Passive adaptation is mainly to realize the adaptation of core business logic to access to basic resources, such as databases, caches, file systems, and message middleware.
• The domain model, domain service, and application service in the red circle together constitute the core business capabilities of the software .

Hexagonal architecture

The hexagonal architecture is also known as the "port adapter architecture".

The core concept of the hexagonal architecture is: applications interact with the outside through ports.

The hexagonal architecture divides the system into two layers , an inner hexagon and an outer hexagon . The functions of the two layers are divided:

• The hexagon in the red circle realizes the core business logic of the application;
• The outer hexagon completes the interaction and access of external applications, drivers, and basic resources . It provides services in the form of API active adaptation for front-end applications , and realizes resource access by relying on inversion and passive adaptation for basic resources .

DDD layered architecture vs tidy architecture vs hexagonal architecture

Comparison and analysis of three microservice architecture models

• Although DDD layered architecture, clean architecture, architectural models show the form of a hexagonal architecture is not the same, but the design of these three models is the micro-architecture service architecture high cohesion and low coupling principle within the perfect embodiment, and their body shining It is the design idea centered on the domain model
• The architecture model uses a layered approach to control the impact of demand changes on the system from the outside to the inside, and gradually reduces the impact of demand from the outside to the inside.
• The user-oriented front-end can quickly respond to external needs for adjustment and release, flexible and changeable
• The application layer uses service composition and orchestration to quickly adapt and launch business processes, reduce the need to be transmitted to the domain layer, and keep the domain layer stable for a long time.

 

Event Driven Architecture (EDA)

Event-driven architecture is a software architecture model. For event-driven systems, the capture, communication, processing and persistent retention of events are the core structure of the solution . This is very different from the traditional request-driven model.

Many modern applications have adopted event-driven design. Because event-driven itself is a programming architecture method, not a programming language , event-driven applications can be created in any programming language. Event-driven architecture can minimize the degree of coupling , so it is an ideal choice for modern distributed application architecture.

The event-driven architecture uses loose coupling , because the event initiator does not know which event user is listening to the event, and the event does not know the subsequent results it produces.

EDA can be understood from two aspects:

1. EDA is an architectural pattern that focuses on asynchronous communication based on generation/consumption . This is mainly in contrast to traditional thread-based synchronization systems.
2. EDA is an architectural model that takes events as the core and provides mechanisms for event generation, routing, consumption and callbacks.

Introduce an example of event-driven architecture in related fields in the process of insurance underwriting business.

The generation of an insurance policy has experienced many sub-domains, business status changes, and the transfer of business data across microservices. This process will generate a lot of domain events, these domain events promote the circulation and role conversion of insurance business data and objects between different microservices and subdomains.

In the following figure, several key processes are listed to illustrate how to use domain event-driven design to drive the underwriting business process .

 

 

CQRS(Command Query Responsibility Segregation) 架构

Command Query Responsibility Segregation ( CQRS ) mode is an architectural system mode, which can separate the command to change the state of the model and the query of the model state .

Essentially, CQRS is a mechanism for separating read and write

Two ways to achieve:

1. The databases at both ends of CQ are shared, and the two ends of CQ are only separated on the upper code; this approach brings the benefits of separation of reading and writing of our code, better maintenance, and there is no data consistency problem at both ends of CQ . Because it shares a database. This architecture is very practical, not only takes into account the strong consistency of the data, but also allows the code to be maintained.

 

2. The database and upper code at both ends of CQ are separated, and then the data of Q is synchronized by the C side, usually through Domain Event . There are two synchronization methods, synchronous or asynchronous . If you need strong consistency at both ends of the CQ , you need to use synchronization; if you can accept the final consistency of the data at both ends of the CQ , you can use asynchronous.

 

Domain event design pattern in microservices

Domain event design pattern between microservices

Domain event processing includes: event construction and release, event data persistence, event bus, message middleware, event reception and processing, etc.