Hello everyone, I am Yi An! Today we talk about the DDD layered architecture
There are many microservice architecture models, such as clean architecture, CQRS and hexagonal architecture and so on. Although the times and backgrounds proposed by each architecture pattern are different, the core concept is to design a "high cohesion and low coupling" architecture to easily realize architecture evolution. The emergence of the DDD layered architecture has made the architectural boundaries more and more clear, and it occupies a very important position in the microservice architecture model.
First, let's talk about the previous architectural models, and then discuss the DDD layered 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 dependent 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.
What is DDD layered architecture?
DDD's layered architecture is constantly evolving. The earliest was the traditional four-tier architecture; later, the four-tier architecture was further optimized to realize the decoupling of each layer from the base layer; later, a context layer was added between the domain layer and the application layer, and the five-tier architecture (DCI) was thus formed.
In the earliest traditional four-tier architecture, the base layer is dependent on other layers, and it is located at the core. According to the idea of layered architecture, it should be the core, but in fact the domain layer is the core of the software, so This dependence is problematic. Later, we adopted the Dependency Inversion Principle (DIP) design, optimized the traditional four-layer architecture, and realized the decoupling of each layer from the base layer.
The DDD layered architecture we are talking about today is an optimized four-tier architecture. In the following picture, from top to bottom are: user interface layer, application layer, domain layer and base layer. What are the main responsibilities of each layer of DDD? Let me introduce them one by one.
-
user interface layer
The user interface layer is responsible for displaying information to the user and interpreting user instructions. The users here may be: users, programs, automated tests and batch scripts, etc.
-
application layer
应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。
此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。
这里我要提醒你一下：在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。
另外，应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过API网关向前端发布。还有，应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
-
领域层
领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
这里我要特别解释一下其中几个领域对象的关系，以便你在设计领域层的时候能更加清楚。首先，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。其次，你要知道，实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
-
基础层
基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。
基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。
比如说，在传统架构设计中，由于上层应用对数据库的强耦合，很多公司在架构演进中最担忧的可能就是换数据库了，因为一旦更换数据库，就可能需要重写大部分的代码，这对应用来说是致命的。那采用依赖倒置的设计以后，应用层就可以通过解耦来保持独立的核心业务逻辑。当数据库变更时，我们只需要更换数据库基础服务就可以了，这样就将资源变更对应用的影响降到了最低。
DDD分层架构最重要的原则是什么？
在《实现领域驱动设计》一书中，DDD分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。
而架构根据耦合的紧密程度又可以分为两种：严格分层架构和松散分层架构。优化后的DDD分层架构模型就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。而传统的DDD分层架构则属于松散分层架构，它允许某层与其任意下方的层发生依赖。
那我们怎么选呢？综合我的经验，为了服务的可管理，我建议你采用严格分层架构。
在严格分层架构中，领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰。而在松散分层架构中，领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理，甚至容易使核心业务逻辑外泄。
试想下，如果领域层中的某个服务发生了重大变更，那该如何通知所有调用方同步调整和升级呢？但在严格分层架构中，你只需要逐层通知上层服务就可以了。
DDD分层架构如何推动架构演进？
领域模型不是一成不变的，因为业务的变化会影响领域模型，而领域模型的变化则会影响微服务的功能和边界。那我们该如何实现领域模型和微服务的同步演进呢？
-
微服务架构的演进
领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文。
实体或值对象的简单变更，一般不会让领域模型和微服务发生大的变化。但聚合的重组或拆分却可以。这是因为聚合内业务功能内聚，能独立完成特定的业务逻辑。那聚合的重组或拆分，势必就会引起业务模块和系统功能的变化了。
这里我们可以以聚合为基础单元，完成领域模型和微服务架构的演进。聚合可以作为一个整体，在不同的领域模型之间重组或者拆分，或者直接将一个聚合独立为微服务。
我们结合上图，以微服务1为例，讲解下微服务架构的演进过程：
-
当你发现微服务1中聚合a的功能经常被高频访问，以致拖累整个微服务1的性能时，我们可以把聚合a的代码，从微服务1中剥离出来，独立为微服务2。这样微服务2就可轻松应对高性能场景。 -
在业务发展到一定程度以后，你会发现微服务3的领域模型有了变化，聚合d会更适合放到微服务1的领域模型中。这时你就可以将聚合d的代码整体搬迁到微服务1中。如果你在设计时已经定义好了聚合之间的代码边界，这个过程不会太复杂，也不会花太多时间。 -
最后我们发现，在经历模型和架构演进后，微服务1已经从最初包含聚合a、b、c，演进为包含聚合b、c、d的新领域模型和微服务了。
你看，好的聚合和代码模型的边界设计，可以让你快速应对业务变化，轻松实现领域模型和微服务架构的演进。你可能还会想，那怎么实现聚合代码快速重组呢？别急，后面实战篇会详细讲解，这里我们先感知下大的实现流程。
-
微服务内服务的演进
在微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装。在服务逐层组合和封装的过程中，你会发现这样一个有趣的现象。
我们看下上面这张图。在服务设计时，你并不一定能完整预测有哪些下层服务会被多少个上层服务组装，因此领域层通常只提供一些原子服务，比如领域服务a、b、c。但随着系统功能增强和外部接入越来越多，应用服务会不断丰富。有一天你会发现领域服务b和c同时多次被多个应用服务调用了，执行顺序也基本一致。这时你可以考虑将b和c合并，再将应用服务中b、c的功能下沉到领域层，演进为新的领域服务（b+c）。这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。
你看，这就是服务演进的过程，它是随着你的系统发展的，最后你会发现你的领域模型会越来越精炼，越来越能适应需求的快速变化。
三层架构如何演进到DDD分层架构？
综合前面的讲解，相信DDD分层架构的优势，你心里也有个谱了。我们不妨总结一下最最重要两点。
首先，由于层间松耦合，我们可以专注于本层的设计，而不必关心其它层，也不必担心自己的设计会影响其它层。可以说，DDD成功地降低了层与层之间的依赖。
其次，分层架构使得程序结构变得清晰，升级和维护更加容易。我们修改某层代码时，只要本层的接口参数不变，其它层可以不必修改。即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。
那我们该怎样转向DDD分层架构呢？不妨看看下面这个过程。
传统企业应用大多是单体架构，而单体架构则大多是三层架构。三层架构解决了程序内代码间调用复杂、代码职责不清的问题，但这种分层是逻辑概念，在物理上它是中心化的集中式架构，并不适合分布式微服务架构。
DDD分层架构中的要素其实和三层架构类似，只是在DDD分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。
我们看一下上面这张图，分析一下从三层架构向DDD分层架构演进的过程。
首先，你要清楚，三层架构向DDD分层架构演进，主要发生在业务逻辑层和数据访问层。
DDD分层架构在用户接口层引入了DTO，给前端提供了更多的可使用数据和更高的展示灵活性。
DDD分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。DDD分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用DAO方式；DDD分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。
仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config等通用的公共的资源类统一放到了基础层。
传统三层架构向DDD分层架构的演进，体现的正是领域驱动设计思想的演进。
三种微服务架构模型的对比和分析
虽然整洁架构、六边形架构、DDD分层架构的架构模型表现形式不一样，但你不要被它们的表象所迷惑，这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想。
我们看下上面这张图，结合图示对这三种架构模型做一个分析。
请你重点关注图中的红色线框，它们是非常重要的分界线，这三种架构里面都有，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。
红色框内部主要实现核心业务逻辑，但核心业务逻辑也是有差异的，有的业务逻辑属于领域模型的能力，有的则属于面向用户的用例和流程编排能力。按照这种功能的差异，我们在这三种架构中划分了应用层和领域层，来承担不同的业务逻辑。
领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的API服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
可以说，这三种架构都考虑了前端需求的变与领域模型的不变。需求变幻无穷，但变化总是有矩可循的，用户体验、操作习惯、市场环境以及管理流程的变化，往往会导致界面逻辑和流程的多变。但总体来说，不管前端如何变化，在企业没有大的变革的情况下，核心领域逻辑基本不会大变，所以领域模型相对稳定，而用例和流程则会随着外部应用需求而随时调整。把握好这个规律，我们就知道该如何设计应用层和领域层了。
架构模型通过分层的方式来控制需求变化从外到里对系统的影响，从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变，应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期稳定。
这样设计的好处很明显了，就是可以保证领域层的核心业务逻辑不会因为外部需求和流程的变动而调整，对于建立前台灵活、中台稳固的架构很有帮助。
看到这里，你是不是已经猜出中台和微服务设计的关键了呢？我给出的答案是：领域模型和微服务的合理分层设计。那么你的答案呢？
从三种架构模型看中台和微服务设计
结合这三种微服务架构模型的共性，下面我来谈谈中台和微服务设计的一些心得体会。
中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应DDD的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。
中台作为子域还可以继续分解为子子域，在子域分解到合适大小，通过事件风暴划分限界上下文以后，就可以定义微服务了，微服务用来实现中台的能力。表面上看，DDD、中台、微服务这三者之间似乎没什么关联，实际上它们的关系是非常紧密的，组合在一起可以作为一个理论体系用于你的中台和微服务设计。
1. 中台建设要聚焦领域模型
中台需要站在全企业的高度考虑能力的共享和复用。
中台设计时，我们需要建立中台内所有限界上下文的领域模型，DDD建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。
因此，在中台设计中我们首先要聚焦领域模型，将它放在核心位置。
2. 微服务要有合理的架构分层
微服务设计要有分层的设计思想，让各层各司其职，建立松耦合的层间关系。
不要把与领域无关的逻辑放在领域层实现，保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。也不要把领域模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终领域模型会失焦。如果实在无法避免，我们可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可以直接将防腐层代码抛弃。
微服务内部的分层方式我们已经清楚了，那微服务之间是否也有层次依赖关系呢？如何实现微服务之间的服务集成？
有的微服务可以与前端应用集成，一起完成特定的业务，这是项目级微服务。而有的则是某个职责单一的中台微服务，企业级的业务流程需要将多个这样的微服务组合起来才能完成，这是企业级中台微服务。两类微服务由于复杂度不一样，集成方式也会有差异。
项目级微服务
项目级微服务的内部遵循分层架构模型就可以了。领域模型的核心逻辑在领域层实现，服务的组合和编排在应用层实现，通过API网关为前台应用提供服务，实现前后端分离。但项目级的微服务可能会调用其它微服务，你看在下面这张图中，比如某个项目级微服务B调用认证微服务A，完成登录和权限认证。
通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在API网关上的应用服务。你看下图中微服务B中红色框内的应用服务B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到API网关供前端调用，这样前端就可以直接访问自己的微服务了。
企业级中台微服务
企业级的业务流程往往是多个中台微服务一起协作完成的，那跨中台的微服务如何实现集成呢？
企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
我们可以在中台微服务之上增加一层，你看下面这张图，增加的这一层就位于红色框内，它的主要职能就是处理跨中台微服务的服务组合和编排，以及微服务之间的协调，它还可以完成前端不同渠道应用的适配。如果再将它的业务范围扩大一些，我可以将它做成一个面向不同行业和渠道的服务平台。
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 does not have a 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 I explained in detail the neat architecture and hexagonal architecture, as well as the layered architecture of DDD. I explained in detail the layered architecture of DDD, which includes user interface layer, application layer, domain layer and base layer. Through these hierarchical divisions, we can clarify the functions of each layer of microservices, delineate the boundaries of objects in each field, and determine the collaboration methods of objects in each field. This architecture not only reflects the requirements of microservice design and architecture evolution, but also integrates the concept of domain model well, and the two are seamlessly combined. Finally, a comparative analysis of the three microservice architecture models including the DDD layered architecture was conducted, and their common characteristics were summarized. Starting from the commonality, several key points of the mid-stage modeling and microservice architecture design were sorted out.
This article is published by mdnice multi-platform