08 Microservice Architectural Models - A Comparison and Analysis of Common Models #

Hello, I’m Ou Chuangxin.

In the previous lecture, I focused on introducing the DDD layered architecture, and I also mentioned that there are many other models of microservice architecture. Did you notice that? These architecture models have high reference value in our practical applications.

Today, we will compare and analyze the DDD layered architecture (for more details, you can review Lecture 07), the Clean Architecture, and the Hexagonal Architecture. We will see how to make good use of them to help us design a highly cohesive and loosely coupled middle platform and microservice architecture.

Clean Architecture #

Clean Architecture, also known as “Onion Architecture,” gets its name from the structure resembling an onion. Just take a look at the image below, and you will understand why it is called the “Onion Architecture.” The layers of Clean Architecture are like the layers of an onion, reflecting the design principle of layering.

In Clean Architecture, concentric circles represent different parts of the application software. From the inside out, they are the domain model, domain services, application services, and the outermost layer containing easily changeable content, such as the user interface and infrastructure.

The main principle of Clean Architecture is the Dependency Rule, which defines the dependency relationships between the layers. Dependencies decrease as we move inward, with higher-level code representing core capabilities. Code in the outer circle can only depend on the inner circle, and the inner circle does not need to know anything about the outer circle.

In the Onion Architecture, the responsibilities of each layer are divided as follows:

The domain model implements the core business logic within the domain, encapsulating enterprise-level business rules. The main component of the domain model is an entity, which can be an object with methods or a collection of data structures and methods.

Domain services implement complex business logic that involves multiple entities.

Application services implement the combination and orchestration of services related to user operations. They encapsulate and implement all the specific business process rules of the application, covering all use cases of the system.

The outermost layer primarily provides adaptation capabilities, which can be active or passive. Active adaptation mainly implements adaptation of the inner-layer business logic for access by external users, web pages, batch processing, and automated testing, among others. Passive adaptation mainly implements adaptation of core business logic for accessing basic resources, such as databases, caches, file systems, and message middleware.

The domain model, domain services, and application services within the red circle together form the core business capabilities of the software.

Hexagonal Architecture #

Hexagonal Architecture, also known as “Ports and Adapters Architecture”, is often mentioned when discussing microservices architecture.

The core idea of Hexagonal Architecture is that an application interacts with the outside world through ports. This is also one of the main reasons why API gateways are popular in the context of microservices architecture.

In the Hexagonal Architecture diagram below, the core business logic (application and domain models) within the red circle is completely isolated from external resources (including apps, web applications, and database resources, etc.) and only interacts through adapters. It solves the problem of intertwining business logic and user interfaces, achieving a good separation between the front-end and back-end. The dependency relationships between the layers in Hexagonal Architecture, just like Clean Architecture, are all from the outside to the inside.

The Hexagonal Architecture divides the system into two layers: the inner hexagon and the outer hexagon. The functions of these two layers are as follows:

The inner hexagon within the red circle implements the core business logic of the application.

The outer hexagon handles the interaction and access of external applications, drivers, and underlying resources, and provides services to front-end applications through API adaptation, and accesses underlying resources through dependency inversion.

In the Hexagonal Architecture, a port can correspond to multiple external systems, and different adapters may be used for different external systems. Adapters are responsible for protocol conversion. This allows the application to be used by users, programs, automated tests, and batch processing scripts in a consistent manner.

Comparison and Analysis of Three Microservice Architecture Models #

Although the architectural models of DDD layered architecture, clean architecture, and hexagonal architecture have different forms, don’t be deceived by their appearances. The design principles of these three architecture models are a perfect embodiment of the microservice architecture’s high cohesion and low coupling principles, and they shine with the design philosophy centered around the domain model.

Let’s take a look at the above diagram and analyze these three architecture models in conjunction with the illustration.

Please pay special attention to the red borders in the diagram, as they are crucial boundaries that exist in all three architecture models. Their purpose is to separate the core business logic from external applications and infrastructure resources.

The red-bordered section mainly implements the core business logic, but the core business logic may differ. Some business logic belongs to the capabilities of the domain model, while others belong to user-oriented use cases and process orchestration capabilities. According to these functional differences, we divide the application layer and the domain layer in these three architectures to handle different business logic.

The domain layer implements the domain model and its core business logic, constituting atomic models. It needs to maintain the stability of the domain model and business logic, providing stable fine-grained domain services to the outside world. Therefore, it occupies a central position in the architecture.

The application layer implements use cases and processes related to user operations, providing coarse-grained API services to the outside world. It acts as a gear that adapts the front-end application to the domain layer, receiving front-end demands and responding and adjusting in real-time, avoiding the transmission of front-end demands to the domain layer as much as possible. The application layer, acting as a speed-matching gear, is located between the front-end application and the domain layer.

It can be said that these three architectures all consider the variability of front-end demands and the invariability of the domain model. Demands are ever-changing, but changes always follow certain rules. Changes in user experience, operating habits, market environment, and management processes often lead to varying interface logic and process flows. However, overall, regardless of how the front-end changes, as long as there is no major transformation in the enterprise, the core domain logic will remain relatively stable. Therefore, the domain model is comparatively stable, while use cases and processes will always be adjusted according to external application demands. Understanding this rule enables us to know how to design the application layer and the domain layer.

Architectural models control the impact of demand changes on the system from the outside in through layering, gradually reducing the impact from outside to inside. The front-end facing users can quickly respond to external demands for adjustments and releases, being flexible and adaptable. The application layer realizes the rapid adaptation and deployment of business processes through service composition and orchestration, reducing the demands transmitted to the domain layer, allowing the domain layer to maintain long-term stability.

The advantages of such a design are evident: it ensures that the core business logic of the domain layer is not adjusted due to external demands and process changes, which is very helpful in building a flexible front-end and a stable middle-end architecture.

By now, have you already guessed the key to designing the middle-end and microservices? The answer I give is: a well-designed layering of the domain model and microservices. What’s your answer?

Analysis of Centralized Platform and Microservices Design from Three Architecture Models #

Combining the commonalities of these three microservices architecture models, I would like to share some insights on the design of centralized platforms and microservices.

The central platform is essentially a subdomain of the domain, which can be the core domain, a generic domain, or a supporting domain. Generally, Alibaba’s centralized platform corresponds to the generic domain of Domain-Driven Design (DDD), where common capabilities are consolidated into the platform and shared with others.

The central platform, as a subdomain, can be further broken down into sub-subdomains. After decomposing the subdomains to an appropriate size and defining the bounded contexts through an event storming process, microservices can be defined to implement the capabilities of the central platform. On the surface, DDD, central platform, and microservices may seem unrelated, but in reality, they are closely related and can be combined as a theoretical framework for designing your centralized platform and microservices.

1. Central Platform Construction Focuses on Domain Models #

When designing the central platform, we need to consider the sharing and reuse of capabilities from an enterprise-wide perspective.

In the design of the central platform, we need to establish domain models for all bounded contexts within the platform. The DDD modeling process considers architectural evolution and the recombination of functionalities. The process of establishing domain models involves clear delineation of logical and physical boundaries (microservices) for business and applications. The result of the domain models will affect the subsequent system models, architecture models, and code models, ultimately impacting the decomposition of microservices and the implementation of projects.

Therefore, in the design of the central platform, we need to prioritize the focus on domain models and place them in a central position.

2. Microservices Should Have a Well-Designed Architectural Layering #

Microservices design should follow a layered design principle, where each layer has its own responsibilities and establishes loosely coupled relationships between layers.

Avoid implementing logic unrelated to the domain in the domain layer to ensure the purity of the domain layer and the stability of the domain logic, and to avoid polluting the domain model. Similarly, do not put business logic related to the domain model in the application layer, as this would result in an excessively large application layer, causing the domain model to lose focus. If this is unavoidable, an anti-corruption layer can be introduced to adapt and transform between new and old systems. Once the transition period is complete, the anti-corruption layer code can be discarded.

The internal layering of microservices is well understood. But what about the layering and integration between microservices? How can microservices integrate with each other?

Some microservices can be integrated with front-end applications to complete specific business processes. These are project-level microservices. Others are specific central platform microservices that fulfill a single responsibility, and enterprise-level business processes require the combination of multiple central platform microservices. These are enterprise-level central platform microservices. The integration methods between these two types of microservices can be different due to differences in complexity.

Project-Level Microservices

For project-level microservices, following a layered architecture model is sufficient. The core logic of the domain model is implemented in the domain layer, while service composition and orchestration are implemented in the application layer. The services are exposed to the front-end applications through an API gateway, enabling front-end and back-end separation. However, project-level microservices may also need to call other microservices. In the diagram below, for example, project-level microservice B calls authentication microservice A to complete the login and permission authentication process.

Typically, the integration between project-level microservices occurs in the application layer of the microservice. The application service in microservice B, as shown in the red-boxed area in the diagram, not only can compose and orchestrate its own domain services but can also compose and orchestrate application services from external microservices. It simply publishes the orchestrated services to the API gateway for front-end access, enabling direct access to the microservices by the front-end applications.

Enterprise-Level Central Platform Microservices

Enterprise-level business processes are often completed through the collaboration of multiple central platform microservices. How can microservices across the central platform be integrated?

The integration of enterprise-level central platform microservices cannot be achieved within a single microservice like project-level microservices, where service composition and orchestration across microservices occur within the application layer.

To address this, an additional layer can be added on top of the central platform microservices. In the diagram below, the added layer is represented by the red-boxed area. Its main role is to handle service composition and orchestration across central platform microservices, as well as coordination between microservices. It can also adapt to different front-end and channel requirements. If its scope is expanded further, it could become a service platform serving different industries and channels.

For now, let’s use the term Backend for Frontends (BFF) to refer to this additional layer, which can be called the BFF microservice. The BFF microservice is significantly different from other microservices because it does not have a domain model. Therefore, it does not have a domain layer. The BFF microservice primarily functions at the application layer and user interface layer, responsible for composing and orchestrating services from various central platform microservices. It can also adapt to the requirements of different front-end applications and channels.

3. Decoupling and Adapting Applications and Resources #

In traditional data-centric design patterns, applications tend to have strong dependencies on databases, caching systems, file systems, and other basic resources.

Because of these strong dependencies, changing basic resources can have a significant impact on applications. Therefore, it is necessary to decouple applications from resources.

In a microservices architecture, decoupling between the application layer, domain layer, and infrastructure layer is achieved through the repository pattern, using the principles of dependency inversion. When designing applications, we also consider code adaptation with basic resources. This allows us to shield the business code from the impact of resource changes, cut off the dependency of business logic on basic resources, and ultimately reduce the impact of resource changes on applications.

Summary #

Today we explained in detail about Clean Architecture and Hexagonal Architecture, and compared and analyzed three microservice architecture models including DDD layered architecture. We summarized their common features and, based on these commonalities, outlined several key points for domain-driven modeling and microservice architecture design. In the future, we will have more detailed discussions on design implementation.

From today’s content, it is not difficult to see that: DDD layered architecture, Clean Architecture, and Hexagonal Architecture all revolve around the domain model, implement layered architecture, and isolate and decouple the core business logic from external applications and resources. Please remember this design thinking, as it will be very useful in the future.