[Architecture] Introduction to several typical architectures of domain-driven design (DDD)

foreword

We have all heard of DDD in our lives and understood DDD, so how to divide and structure a new project from scratch according to the process of DDD?

1. Terminology

• various services
  • IAAS: Infrastructure as a service, Infrastructure-as-a-service
  • PAAS: Platform service, Platform-as-a-service
  • SAAS: software service, Software-as-a-service

2. Architecture Evolution

From the figure, it is easy to see the evolution process of the architecture, which is illustrated by examples of three layers:

• SAAS: For example, our earliest application was a single application, and multiple businesses may not be layered. Later, when we had more businesses, they were all mixed together. Later, we dismantled the business through MVC, SSM, and layering. To ensure the decoupling between business and business
• PAAS: With the growth of business, we intend to separate a subsystem, but the cost is too high, and we need to build a subsystem from scratch every time, which is inefficient. At this time, we extract some common technologies, such as mesh, SOA, microservices, etc. to isolate the system, and reuse common technologies to quickly build a system
• IAAS: For example, the order service has a high concurrency, and a single server can no longer meet the requirements. At this time, we need multiple servers, which may include windows, linux, and mac. If you want to deploy quickly, you need to shield the OS, so there are VM and Docker , K8S and other technologies to shield the OS

3. Upper and lower limits

Bounded context concept

The relationship between BC and business:
through the division of business, such as the order system, the order is a subdomain; the inventory is a subdomain; the meanings of commodities in different subdomains are also different, such as commodities in the order context Indicates the unit price, discount, etc. of the product; while in the context of inventory, the product represents the inventory, cost, storage location, etc. of the product.
The relationship between BC and technology:
multiple subdomains must be aggregated at the application layer, and the process of aggregation leads to technical solutions, such as order to inventory to payment, they should be synchronized; these subdomain call notifications are all It should be asynchronous, so message middleware or other technical solutions may be required
Bounded context division rules

Generally speaking, consider the team size first to decide how fine-grained BC needs to be divided into. If the team size is too small and the BC is too fine, it will cause a great burden on the later operation and maintenance, deployment, and online; After the granularity, you can divide the semantic correlation, functional correlation-business direction, functional correlation-non-business direction. After dividing according to the above rules, you can get multiple BCs. Does a BC represent a
microservice ?

Concept : Microservice generally refers to a development and deployment unit of highly related functions, with its own technical autonomy, technology selection, elastic expansion and contraction, release frequency, etc. To put it bluntly, each maintains one business, and then multiple businesses Form a system and manage
relationships among multiple businesses: BC here is actually a domain or a module or a business. If the two domains are highly correlated, multiple BCs can be included, or if a domain has a very large number of visits. Large, it needs to be deployed in a microservice to improve performance

4. Four Boundaries of Domain-Driven Design

As shown in the figure above, we design the architecture through four layers:
divide and conquer : DDD rationally solidifies and layers the domain knowledge by planning the four layers of boundaries. The business has a core domain and a supporting domain, and the business domain is divided into multiple bounded contexts (BC), and a BC is layered according to whether the domain knowledge is core or not. In the domain layer, multiple business (subdomain) strengths Dependencies are aggregated into a subdomain. In addition, search the backend architect of the official account and reply "the structure is neat" in the backstage, and get a surprise gift package.
[The first boundary] Determine the vision and goals of the project, determine the problem space, determine the core sub-fields, general sub-fields (multiple sub-fields can be reused), supporting sub-fields (additional functions, such as data statistics, export reports) [Part 2
] Double boundary] The bounded context in the solution space is a physical boundary at the process isolation level
[Third boundary] Each bounded context is divided into: interface layer, domain layer, application layer, and infrastructure layer using a layered architecture The minimum isolation between
[the fourth boundary] In order to ensure the integrity and consistency of each domain in the domain layer, the design of aggregation is introduced as the smallest unit of the isolated domain model

5. Tidy layered architecture

For specific instructions, see the notes in the figure. Generally speaking, the domain layer is separated from the interface to make the domain layer as independent as possible without coupling with any modules. This includes the business logic code of the domain model, but it does not depend on specific technical implementations. , it is very convenient to replace the infrastructure layer and provide it to the third-party web call service

Six, hexagonal structure

Active adaptation: refers to input commands from the UI, command line, etc. The controller is a kind of port, and the specific implementation of the port is the application logic itself. Therefore, both the port and the specific implementation are inside the application system.
Passive adaptation: refers to accessing storage devices, external services, etc. Each type of access is a kind of port, and the specific implementation is each specific middleware. Therefore, the port is inside the entire application system, and the specific implementation is outside the system. Each input and output is a port, and each port has specific implementation logic, so the architecture of the entire application system is composed of a series of ports + adaptation logic, and the architecture diagram is a polygonal shape. There are several ports that need to be determined according to the specific conditions of the application system, but the six ports are more vivid, so it is called the hexagonal architecture. Features: 1. The outer layer depends on the inner layer to make the dependency more reasonable. A port is an interface, relying on interface programming. This ensures isolation between application and implementation details. 2. Testable is better

7. Onion Architecture

For the hexagonal architecture, the onion architecture further divides the business logic of the inner layer into the application service layer, domain service layer and domain model layer of the DDD concept.
Features:

1. Build applications around independent domain models
2. The inner layer defines the interface, and the outer layer implements the interface
3. The direction of dependency points to the center of the circle (note: the onion architecture advocates that it is reasonable to rely on dependencies that do not break the coupling direction. The outer layer can depend on the direct inner layer or the inner layer)
4. All application code can be compiled and run independently of the infrastructure

Summarize

At present, domain-driven design is a popular architecture design. It only needs to design the architecture according to the four boundaries of domain-driven design, and it can decouple various domains well, and support the vertical expansion of business and the horizontal expansion of functions in the later period. Provides a good foundation.