DDD的分层架构设计
DDD的分层架构设计
几种微服务架构模型对比分析
整洁架构
整洁架构又名“洋葱架构”。为什么叫它洋葱架构？因为整洁架构的层就像洋葱片一样，它体现了分层的设计思想。
在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。 整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。
在洋葱架构中，各层的职能是这样划分的：
- 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实 体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
- 领域服务实现涉及多个实体的复杂业务逻辑。
- 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则， 封装和实现了系统所有用例。
- 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外 部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
六边形架构
六边形架构又名“端口适配器架构”。六边形架构的核心理念是：应用是通过端口与外部进行交互的。
也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依 赖关系与整洁架构一样，都是由外向内依赖。
六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：
- 红圈内的六边形实现应用的核心业务逻辑；
- 外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配 的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测 试和批处理脚本使用。
DDD 分层架构
按照职责，将架构分为了四层，用户接口层、应用层、领域层和基础层，架构图如下所示：
用户接口层
用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化 测试和批处理脚本等等。
应用层
应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。 但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和 领域对象完成服务编排和组合，协作完成业务操作。此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务 之间的服务组合和编排。
另外，应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行 顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。还有，应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
领域层
领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要 体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。那么这几个对象有什么关系呢？
- 首先，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。
- 其次，实体和领域对象在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
基础层
基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。
基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。
分层架构的原则
在《实现领域驱动设计》一书中，DDD 分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。
而架构根据耦合的紧密程度又可以分为两种：严格分层架构和松散分层架构。
- 在严格分层架构中，领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰。
- 而在松散分层架构中，领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理，甚至容易使核心业务逻辑外泄。
DDD分层架构与三层架构
DDD 分层架构中的要素其实和三层架构类似，只是在 DDD 分层架构中，这些要素被重新 归类，重新划分了层，确定了层与层之间的交互规则和职责边界。
从图上可以看出，主要差异其实在业务逻辑层与数据访问层。
DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻 辑混乱，代码改动相互影响大的情况。DDD 分层架构将业务逻辑层的服务拆分到了应用层 和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式； DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖 倒置实现各层对基础资源的解耦。
仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。 原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资 源类统一放到了基础层。
仓储模式是一种设计模式。它是在应用业务逻辑和数据层之间增加的一个抽象层，应用逻辑通过调用仓储接口的方式与数据层交互，与数据相关的实现都在仓储实现中实现，这样就可以避免在应用逻辑中混入数据相关的实现逻辑。从而就解耦了应用逻辑和数据逻辑。在基础资源 变化时不会对应用逻辑有太大的影响。
对比分析
DDD 分层架构、整洁架构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离并解耦。
它们几个其实是一点一点继承和发展过来的，在大的分层上基本上没什么太大的差异， 思路基本是一致的，都是以领域模型为中心，加上用于编排的应用层逻辑。但是在分层的内部有 一些小的差异。包括外部的适配方式也有差异。
红色框内部主要实现核心业务逻辑，但核心业务逻辑也是有差异的，有的业务逻辑属于领域模型的能力，有的则属于面向用户的用例和流程编排能力。按照这种功能的差异，我们在这三种架构中划分了应用层和领域层，来承担不同的业务逻辑。
领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
架构模型通过分层的方式来控制需求变化从外到里对系统的影响，从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变，应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期 稳定。
COLA 架构
这里插个题外话，COLA是阿里巴巴自研的应用架构，我们公司自研的DDD架构（当然，现在回顾起来我们自研的架构跟人家比差的不是一点半点……后续慢慢把我个人理解的架构实践整理下）以及上面提到的DDD分层架构与COLA有很多相似之处。今天整理笔记的时候仔细看了下COLA4.0的架构图，感觉有一处很棒的设计：防腐层。COLA的架构图如下：
防腐层：简单的说，应用不要直接依赖外域的信息，要把外域的信息转换成自己领域上下文（Context）的实体再去使用，从而实现本域和外部依赖的解耦。主要是在Domain层定义Gateway接口，然后在Infrastructure提供Gateway接口的实现。
再多的细节就不说了，可以查看大佬的博客：https://blog.csdn.net/significantfrank/article/details/110934799
部分内容摘自极客《DDD实战》