六边形架构补充 - 第五章 - DDD领域模型

六边形架构

六边形架构的由基础设施层、用户接口层、应用层和领域层组成。领域层封装核心的业务逻辑，然后由应用层进行业务逻辑的编排。接口层和基础设置层在六边形架构中分别属于输入端口和输出端口，然后在进行端口的适配。

领域层： 位于最底部，是整个系统的核心。它封装了最纯粹的业务逻辑（实体、规则、流程），不依赖于任何外部层次（如应用层、基础设施层）。它是系统中最稳定、最不易变化的部分。
应用层： 位于领域层之上。它负责协调和编排领域对象来完成具体的用例或用户故事（例如“用户下单”、“审批流程”）。它依赖于领域层，并可能调用基础设施层（如图中箭头所示）来辅助完成工作（如发送消息、访问文件）。
用户接口层： 位于应用层之上。它负责处理用户的输入（如HTTP请求、命令行指令），并将其转化为应用层能理解的指令。它依赖于应用层（也可能直接调用领域层，但更佳实践是通过应用层），同时也依赖基础设施层提供的具体技术实现（如Web框架、序列化工具）。
基础设施层： 位于最外层（图中最上方）。它包含了所有具体的技术实现细节，如数据库存取、消息队列、外部API调用、文件系统操作等。它的依赖方向是关键：在整洁架构中，基础设施层实现领域层或应用层定义的抽象接口（端口），因此箭头在图上虽然从下层指向它，但代码依赖关系是倒置的

层与层之间调用关系

如下图所示：

整个流程遵循“请求驱动”与“事件驱动”两条主线：

1. 同步请求处理流（自上而下）
   入口： 来自应用终端的请求，首先到达API网关。
   控制流转： API网关将请求路由至用户接口层的Facade。Facade调用应用层的应用服务。
   业务执行： 应用服务编排领域层的聚合和领域服务执行业务逻辑。在此过程中，应用服务通过仓储接口获取或保存数据。
   数据持久化： 仓储接口的具体调用，会由基础层的仓储实现来执行，从而操作DB或文件。

2. 异步事件驱动流（通过消息队列）
   内部事件发布： 当应用层完成某个操作（如订单已支付），其事件发布组件会向消息队列发布一个领域事件。
   外部服务消费： 外部的其他微服务（图下方微服务外模块）会订阅该事件，并在其应用服务中处理，实现系统间的解耦集成。
   响应外部事件： 同样，外部微服务发布的事件，会被本系统应用层的事件订阅组件监听，并触发本系统的应用服务做出响应，完成业务闭环。

清晰架构

如下图所示：

这张图片的核心内容是阐述了“清晰架构”（Clean Architecture，常被称为“洋葱架构”）的核心设计理念与运行机制。

1. 核心模式：以领域模型为中心的同心分层

架构图像一个洋葱，由内到外是：
最内层 - 领域层： 包含核心业务实体与规则，是系统中最稳定、最纯粹的部分。
中间层 - 应用层： 包含应用服务，负责编排领域对象来实现具体的用例，它依赖于领域层。
最外层 - 接口与基础设施： 包含用户界面（UI）、API、数据库等具体实现细节。这一层是易变的，会随技术选型而改变。
最关键的原则是： 依赖永远指向内部。外层依赖内层，内层对外层一无所知。这意味着业务逻辑完全独立于数据库、Web框架等外部技术。

2. 关键机制：端口与适配器

这是架构实现“依赖倒置”的具体手段：
端口： 由内层（领域/应用层）定义的抽象接口（例如，一个仓储接口）。它声明“系统需要什么功能”。
适配器：
主/主动适配器（如HTTP控制器、CLI命令）： 将外部输入（如HTTP请求）适配成对内部应用服务的调用。
从/被动适配器（如数据库ORM实现、消息客户端）： 适配内部定义的端口，提供具体的技术实现（如连接MySQL）。
通过这个机制，外部世界的任何变化，都只需要更换或修改对应的“适配器”，而核心业务代码纹丝不动。