可落地的DDD(6)-工程结构
背景
几年前我在可落地的DDD的(2)-为什么说MVC工程架构已经过时总结了基于DDD的微服务工程结构是怎么样的。那篇文章重点阐述了与MVC架构的区别。导致一些细节没有讲清楚，本文结合最近两年的实践，再详细阐述下。
应用拆解
请添加图片描述
为了实现一个端到端的用户请求，后端服务按照调用链一般可以分成四层
- 用户接口 应用作为provider，封装领域服务，提供给外部调用。处理用户命令与展示。这一层的价值在于防止领域模型的泄露。包括提供给本地其他领域调用、rpc调用、前端的http调用。
- 应用服务 很薄的一层，主要是面向usecase的。可以协调多个领域服务完成用户接口。
- 领域服务 领域服务层，即我们通常说的领域模型。领域内的属性、行为、事件、规则通过领域服务、领域事件、实体、值对象这些有序的组织起来。
- 基础设施 应用依赖的外部资源，包括存储、外部接口、消息等。
架构模式
应用被拆成四层，每一层有自己的作用。现在我们需要做的就是有效的组织这四层，以领域模型为中心，合理分层，高内聚、低耦合，隔离并解耦内部核心业务逻辑与外部应用和资源。业界比较常见的有以下几种。
分层架构
左边是传统的四层架构，即还是以调用顺序组织的。右边是依赖倒置的。
所谓依赖倒置即虽然按照运行时的调用关系是A依赖B,但是我在编译环节是让B依赖A。即A提供接口，B来实现。主要是两点
- 领域层不再依赖其他任何一层，这样能够实现具体的技术实现不会影响业务，不用纠结到底如何持久化，如何发消息。定义接口，让基础设施层实现。这样可以让领域模型易测试，易维护。
- 基础层依赖其他各层，包括领域层、接口层、应用服务层。
关于基础设施层是否依赖接口层，这点个人持怀疑态度。从实践来看。基础设施层的迭代频率要低于接口层，抽象程度高于用户接口层。从依赖角度来说，让用户接口层依赖基础设施层更合适。
下图是我们常用的分层架构。
六边形架构
请添加图片描述
网络用图，如有侵权，联系删除
六边形架构通过内外两个六边形将领域层和其他部分分割成两部分。对于其他部分，提出了2个概念。
- 端口(port) 即应用的入口和出口，是应用同外部交流的唯一通道。一般是以接口的形式存在。端口是在领域服务层。
- 适配器（adaptor） 与port相关联。对于入口层（用户接口层）是依赖调用。对于出口层（基础设施层)是接口实现的关系。适配器是在非领域层。
举个例子，用户取消支付，系统需要发布消息。领域层提供入口端口CancelPayService，出口端口sendCancelPayMsg 用户接口层在controller中调用CancelPayService. 基础设施层实现sendCancelPayMsg接口，发送一条消息到kafka。
整洁架构
请添加图片描述
网络用图，如有侵权，联系删除
整洁架构是在分层架构基础上，更清晰的定义了各层的依赖关系。按照从内到外，定义了各层的重要等级。越往里，代码越核心，依赖就应该越少。外圆依赖内圆，内圆无需感知外圆。
基础设施 -> 用户接口 -> 应用服务 -> 领域服务
菱形对称架构
请添加图片描述
网络用图，如有侵权，联系删除
菱形架构是去掉了用户接口层和基础设施层这个概念，改成叫网关，同时通过南北网关来区分。
只是换了个说法，本质上没什么区别。
总结
分层、六边形、整洁、菱形架构本质上没什么区别，都是分层。通过不同的维度来把各层关系的依赖关系阐述的更清晰。核心点在于
- 其他层依赖领域层，领域层不依赖任何外部内容
- 领域层通过端口与外部交互。这两点非常重要，能够帮助开发者专注在领域模型的开发上，而不是纠结与其他层的交互上。
至于其他层是否有明确的依赖关系是次要点，可以忽略。