DDD领域驱动设计实战（七）-分层架构的“前世今生”

设为“星标”，好文章不错过！

整洁架构、CQRS、六边形等微服务架构，都是为实现“高内聚低耦合”。而DDD分层架构的出现，使架构边界变得更清晰，在微服务架构举足轻重。

1 DDD分层架构

原则：每层仅可与其下方的层发生耦合。

分层架构也分为两种

严格分层架构(Strict Layers Architecture)

某层只能与直接位于其下方的层发生耦合

松散分层架构(Relaxed Layers Architecture)

允许任意上、下方层间耦合。由于用户接口层和应用服务通常需与基础设施打交道，许多系统都是基于该架构

较低层有时也可和较高层耦合，但仅限于使用观察者 (Observer)模式或者调停者(Mediator)模式的场景。

较低层绝对不能直接访问较高层。例如，在使用调停者模式时，较高层可能实现了较低层定义的接口，然后将实现对象作为参数传递到较低层。当较低层调用该实现时， 它其实还是不知道实现出自何处。

1.1 传统的四层架构

将领域模型和业务逻辑分离出来，并减少对基础设施、用户接口甚至应用层逻辑的依赖，因为它们不属业务逻辑。将复杂系统分层，每层都应该有良好内聚性，且只依赖比较低层。

该架构下的基础设施层位于最底层，持久化和消息（e.g.  MQ所发消息、SMTP邮件或者SMS文本消息）机制便处于此处。基础设施层是应用程序的低层服务，被较高层发生耦合并复用。

1.2 优化后的四层架构

将基础设施层放在最底层存在缺点

比如领域层中的一些技术实现是令人头疼的。因为违背了分层原则。也很难为编写测试。

使用依赖反转设计原则，低层服务（比如基础设施层）应依赖高层组件（比如用户接口层、应用层和领域层）的接口。

在使用依赖倒置原则的分层。基础设施层在最上方实现所有其他层中定义的接口

依赖反转支持所有层？

有人认为依赖反转原则中只存在两层，上层实现下层定义的抽象接口。因此上图的基础设施层将位于最上方，而用户接口层、应用层和领域层应作同层、且都位于下方。

2 各层意义

2.1 用户接口层

只用于处理用户显示和用户请求，不应包含领域或业务逻辑。有人可能认为，既然用户接口需要验证用户输入，那就应该包含业务逻辑。事实上，用户接口所进行的验证和对领域模型的验证不同。对那些粗制滥造且只面向领域模型的验证行为，应该予以限制。

如果用户接口使用了领域模型中的对象，那么此时领域对象仅限于数据的渲染展现。在采用这种方式时，可以使用展现模型对用户接口与领域对象进行解耦。

由于用户可能是人，也可能是其他的系统，有时用户界面层将采用开放主机服务的方式向外提供API。

用户界面层是应用层的直接客户。

用户接口层很重要，主要前后端调用的适配。如果你的微服务要面向很多的应用或渠道提供服务，而每个渠道的入参和出参都不一样，你不太可能开发出太多的应用服务，这样Facade接口就起很好的作用了，包括DO和DTO对象的组装和转换等。

2.2 应用层

理论上不应有业务规则或逻辑，主要面向用例和流程相关的操作。但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。

应用层也是微服务间交互通道，它可调用其它微服务的应用服务，完成微服务之间的服务组合和编排。

设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑混乱。

应用服务是在应用层，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过API网关向前端发布。

应用服务还可进行安全认证、权限校验、事务控制、发送或订阅领域事件等。

2.3 领域层

领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。

实体和领域服务在实现业务逻辑上不是同级，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。

2.4 基础层

基础层贯穿所有层，为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、MQ、网关、文件、缓存以及DB等。比较常见的功能还是提供DB持久化。

基础层包含基础服务，它采用依赖反转，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。

在传统架构设计中，由于上层应用对数据库的强耦合，很多公司在架构演进中最担忧的可能就是换DB，因为一旦更换，就可能需重写大部分代码。那采用依赖反转设计后，应用层就可以通过解耦保持独立核心业务逻辑。当数据库变更时，只需更换数据库基础服务。

微服务架构的演进

领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文。

实体或值对象的简单变更，一般不会让领域模型和微服务发生大变化。但聚合的重组或拆分却可以。这是因为聚合内业务功能内聚，能独立完成特定的业务逻辑。那聚合的重组或拆分，势必就会引起业务模块和系统功能变化。

这里我们可以聚合为基础单元，完成领域模型和微服务架构的演进。聚合可以作为一个整体，在不同的领域模型之间重组或者拆分，或者直接将一个聚合独立为微服务。

以微服务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分层架构在用户接口层引入了DTO，给前端提供了更多的可使用数据和更高的展示灵活性。

DDD分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。DDD分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。

另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用DAO方式；DDD分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。

关于仓储。仓储本身属于基础层，但考虑到一个聚合对应一个仓储，为了以后聚合代码整体迁移方便，在微服务代码目录设计时，在聚合目录下增加一个Repository的仓储目录，跟仓储相关的代码都在这个目录下。

这个目录下的代码与聚合的其它业务代码是分开的。如果未来换数据库，只需将Repository目录下的代码替换。而如果聚合需要整体迁移到其它微服务中去，仓储的代码也会一并迁移。

仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config等通用的公共的资源类统一放到了基础层。

总结‍‍‍‍

DDD分层架构包含用户接口层、应用层、领域层和基础层。通过这些层次划分，我们可以明确微服务各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。

参考

《实现领域驱动设计》

DDD分层架构：有效降低层与层之间的依赖

《领域驱动设计》