“极客时间”《DDD 实战》课程笔记 （三）分层架构与微服务「重要」
这是一系列学习笔记，对象是 极客时间 上面的收费课程 《 DDD实战 》。上一篇笔记介绍了领域事件的使用，这一篇记录一下关于分层架构的知识点。
大家搞网络开发都不是一年两年了，对MVC分层架构都非常熟悉。这是一套面向过程的设计，是一套好的设计；但和领域分层还不能相提并论。
下面是DDD的分层设计图，从上到下依次是：用户接口层、应用层、领域层和基础层。下面来逐一介绍每一层：
用户接口层
用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等。
应用层
应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。
但应用层又位于领域层之上，领域层包含多个聚合，应用层可以协调多个聚合的服务和领域对象完成服务编排和组合。此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务。
应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
注意不要将本该在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失去焦点，使微服务演化为传统的三层架构，业务逻辑会变得混乱。
领域层
领域层的作用是实现企业核心业务逻辑，包含各种校验手段。
领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。领域层包含聚合根、实体、值对象、领域服务等。业务逻辑主要是由实体和领域服务来实现，其中实体会采用充血模型来实现所有与之相关的业务功能。实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
基础层
基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。主要还是提供数据库持久化。
基础层包含基础服务，采用依赖倒置设计实现应用层、领域层与基础层的解耦。比如说，在传统架构设计中，由于上层应用对数据库的强耦合，很多公司在架构演进中最担忧的可能就是换数据库了，因为一旦更换数据库，就可能需要重写大部分的代码，这对应用来说是致命的。那采用依赖倒置的设计以后，应用层就可以通过解耦来保持独立的核心业务逻辑。当数据库变更时，我们只需要更换数据库基础服务就可以了，这样就将资源变更对应用的影响降到了最低。
从这一点能够看出来，mybatis就是典型违反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）。这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。
从MVC到DDD
MVC 是单体服务的架构，其实和DDD分层差不多，只是不同要素分布在了不同层中。
三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。
DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、工具栏、Config 等通用的公共的资源类统一放到了基础层。
其实MVC向 DDD 分层架构的演进，体现的正是领域驱动设计思想的演进。
- 分享到
-
-
