In the last article, I focused on the DDD layered architecture. At the same time, I also mentioned that there are actually many types of microservice architecture models. I wonder if you noticed it?
These architectural models have high reference value in our practical application. So today we will put together the three architecture models of DDD layered architecture (if you forget the details), neat architecture, and hexagonal architecture, compare and analyze, see how to make good use of them, and help us design High cohesion and low coupling middle platform and microservice architecture.
clean architecture
Clean Architecture is also known as "Onion Architecture". Why is it called an onion architecture? Take a look at the picture below and you will understand. The layers of a clean architecture are like slices of an onion, which embodies the idea of layered design.
In the clean architecture, the concentric circles represent different parts of the application software, from the inside to the outside are the domain model, domain services, application services and the most peripheral easy-to-change content, such as user interface and infrastructure.
The most important principle of a clean architecture is the dependency principle , which defines the dependencies of each layer. The lower the dependency is, the higher the code level is, and the more core capabilities it is. The code dependencies of the outer circle 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 realizes the core business logic in the domain, and it encapsulates the business rules of the enterprise level. 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 services implement complex business logic involving multiple entities.
- Application service implements service composition and orchestration related to user operations, which includes application-specific business process rules, and encapsulates and implements all use cases of the system.
- The outermost layer mainly provides the adaptation capability, and the adaptation capability is divided into active adaptation and passive adaptation. Active adaptation mainly realizes the adaptation of external users, web pages, batch processing and automated testing to internal business logic access. 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 form the core business capability of the software.
hexagonal architecture
The hexagonal architecture is also known as the "port adapter architecture". Tracing the origin of the microservice architecture generally involves the hexagonal architecture.
The core idea of the hexagonal architecture is that applications interact with the outside through ports. I think this is also the main reason for the prevalence of API gateways under the microservice architecture.
That is to say, in the hexagonal architecture in the figure below, the core business logic (application and domain model) in the red circle is completely isolated from external resources (including APP, web application, and database resources, etc.), and only interacts through adapters. It solves the problem of code interleaving between business logic and user interface, and achieves a good separation of front and back ends. The dependencies of each layer of the hexagonal architecture are the same as the neat architecture, which is dependent from the outside to the inside.
The hexagonal architecture divides the system into two layers: inner hexagon and outer hexagon. The functions of these two layers are divided as follows:
- The hexagon in the red circle implements 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 for front-end applications in the form of API active adaptation, and implements resource access for basic resources in the form of dependency inversion passive adaptation.
One port of the hexagonal architecture may correspond to multiple external systems, and different external systems may use different adapters, and the adapters are responsible for protocol conversion.
This enables the application to be used in a consistent manner by users, programs, automated tests and batch scripts.
Comparison and Analysis of Three Microservice Architecture Models
Although the architectural models of DDD layered architecture, tidy architecture, and hexagonal architecture have different expressions, don't be confused by their appearance. The design ideas of these three architectural models are exactly the principle of high cohesion and low coupling in microservice architecture The perfect embodiment of them, and what shines on them is the design idea centered on the domain model.
Let's look at the picture above and analyze the three architecture models in combination with the diagram.
Please pay attention to the red wireframes in the figure. They are very important dividing lines, which are found in all three architectures. Their function is to isolate the core business logic from external applications and basic resources.
The core business logic is mainly implemented inside the red box, but the core business logic is also different. Some business logic belongs to the domain model capability, and some belongs to the user-oriented use case and process orchestration capability. According to this functional difference, we divide the application layer and domain layer in these three architectures to undertake different business logic.
The domain layer implements the domain model and implements the core business logic of the domain model. It belongs to the atomic model. It needs to maintain the stability of the domain model and business logic, and provide stable and fine-grained domain services externally, so it is at the core of the architecture.
The application layer implements use cases and processes related to user operations, and provides coarse-grained API services externally. It is like a gear that adapts the foreground application and the domain layer, receives the foreground requirements, responds and adjusts at any time, and tries to avoid transmitting the foreground requirements to the domain layer. The application layer, as a gear, is located between the foreground application and the domain layer.
It can be said that these three architectures take into account the changes in front-end requirements and the invariance of the domain model. Demands are ever-changing, but there are always rules to follow. Changes in user experience, operating habits, market environment, and management processes often lead to changes in interface logic and processes. But in general, no matter how the front-end changes, the core domain logic will basically not change greatly if there is no major change in the enterprise, so the domain model is relatively stable, and the use cases and processes will be adjusted at any time according to external application requirements. Grasping this law well, we will know how to design the application layer and domain layer.
The architectural model controls the impact of demand changes on the system from the outside to the inside in a layered manner, 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, which is flexible and changeable. The application layer realizes the rapid adaptation and launch of business processes through service composition and orchestration, reduces the need for transmission to the domain layer, and maintains the long-term stability of the domain layer.
The advantage of this design is obvious, that is, it can ensure that the core business logic of the domain layer will not be adjusted due to changes in external requirements and processes, which is very helpful for establishing a flexible front-end and a stable middle-end architecture.
Seeing this, have you already guessed the key to the design of the middle platform and microservices? The answer I give is: reasonable layered design of domain model and microservices . So what's your answer?
Looking at the middle platform and microservice design from three architectural models
Combining the commonality of these three microservice architecture models, let me talk about some experience in the middle platform and microservice design.
The middle platform is essentially a subdomain of the domain, which may be the core domain, or the general domain or supporting domain. It is generally believed that Ali's middle platform corresponds to the general domain of DDD, and the general public capabilities are precipitated into the middle platform to provide general shared services to the outside world.
As a subdomain, the middle station can be further decomposed into sub-subdomains. After the subdomain is decomposed to an appropriate size, and the bounded context is divided through the event storm, microservices can be defined, and microservices are used to realize the capabilities of the middle station. On the surface, there seems to be no connection between DDD, middle platform, and microservices. In fact, their relationship is very close. Together, they can be used as a theoretical system for your middle platform and microservice design.
1. The construction of China and Taiwan should focus on the domain model
The middle office needs to consider the sharing and reuse of capabilities from the perspective of the entire enterprise.
When designing the middle platform, we need to establish domain models of all bounded contexts in the middle platform. The evolution of the architecture and the recombination of functions will be considered during the DDD modeling process. The process of establishing the domain model will clearly divide the logical and physical boundaries (microservices) of the business and application. The results of the domain model will affect the subsequent system model, architecture model and code model, and ultimately affect the splitting of microservices and project implementation.
Therefore, in the mid-stage design, we must first focus on the domain model and put it at the core.
2. Microservices must have a reasonable architectural layering
Microservice design must have a layered design idea, let each layer perform its duties, and establish a loosely coupled relationship between layers.
Do not put domain-independent logic in the domain layer to ensure the purity of the domain layer and the stability of the domain logic, and avoid polluting the domain model. Do not put the business logic of the domain model in the application layer, which will cause the application layer to be too large, and eventually the domain model will lose focus. If it is really unavoidable, we can introduce an anti-corrosion layer to adapt and convert the old and new systems. After the transition period is completed, the anti-corrosion layer code can be directly discarded.
We have already understood the layering method inside microservices, so is there any hierarchical dependency between microservices? How to achieve service integration between microservices?
Some microservices can be integrated with front-end applications to complete specific businesses together. These are project-level microservices. And some are mid-stage microservices with a single responsibility. Enterprise-level business processes need to be combined with multiple such microservices to complete. This is an enterprise-level mid-stage microservice. Due to the different complexity of the two types of microservices, the integration methods will also be different.
Project-level microservices
The internals of project-level microservices follow the layered architecture model. The core logic of the domain model is implemented at the domain layer, and the combination and orchestration of services is implemented at the application layer. Services are provided for front-end applications through API gateways to achieve separation of front-end and back-end. However, project-level microservices may call other microservices. You can see in the picture below, for example, a project-level microservice B calls authentication microservice A to complete login and authorization authentication.
Usually, the integration between project-level microservices occurs at the application layer of the microservices, and the application services call the application services published by other microservices on the API gateway. Look at the application service B in the red box in the microservice B in the figure below. In addition to combining and orchestrating its own domain services, it can also combine and orchestrate application services of external microservices. It only needs to publish the orchestrated service to the API gateway for the front-end to call, so that the front-end can directly access its own microservices.
Enterprise-level mid-stage microservices
Enterprise-level business processes are often completed through the collaboration of multiple mid-stage microservices. How to integrate cross-middle-stage microservices?
The integration of enterprise-level mid-stage microservices cannot complete cross-microservice service composition and orchestration within a certain microservice like project-level microservices.
We can add a layer on top of the middle-end microservices. Look at the picture below. The added layer is located in the red box. Its main function is to handle service composition and orchestration across middle-end microservices, as well as Coordination between services, it can also complete the adaptation of front-end applications in different channels. If I expand its business scope, I can make it a service platform for different industries and channels.
We might as well borrow the term BFF (Backend for Frontends), and call it BFF microservices for the time being. There is a big difference between BFF microservices and other microservices, that is, it has no domain model, so there will be no domain layer in this microservice. BFF microservices can undertake the main functions of the application layer and user interface layer, complete the service combination and orchestration of various middle-end microservices, and can adapt to the requirements of different front-ends and channels.
3. Decoupling and adaptation of applications and resources
In the traditional data-centric design pattern, applications will rely heavily on basic resources such as databases, caches, and file systems.
It is precisely because of the strong dependence between them that once we replace the basic resources, it will have a great impact on the application, so it is necessary to decouple the application and resources.
In the microservice architecture, the decoupling of the application layer, domain layer, and base layer is achieved through the warehouse model and the design method of dependency inversion. In the application design, we will simultaneously consider the code adaptation of the basic resources. Once the infrastructure resources change (such as changing the database), we can shield the impact of resource changes on the business code and cut off the dependence of the business logic on the basic resources. Ultimately reduce the impact of resource changes on applications.
Summarize
Today we explained the neat architecture and the hexagonal architecture in detail, and compared and analyzed three microservice architecture models including the DDD layered architecture, summed up their common characteristics, and sorted out the middle Several key points of platform modeling and microservice architecture design, we will have a more detailed description of the design implementation later.
It is not difficult to see from today's content: DDD layered architecture, neat architecture, and hexagonal architecture are all centered on the domain model, implementing a layered architecture, and the internal core business logic is isolated and decoupled from external applications and resources. Please be sure to remember this design idea, it will be of great use in the future.