可落地的DDD-工程结构

Posted 2022-06-28 方丈的寺院

背景

几年前我在可落地的DDD的(2)-为什么说MVC工程架构已经过时总结了基于DDD的微服务工程结构是怎么样的。那篇文章重点阐述了与MVC架构的区别。导致一些细节没有讲清楚，本文结合最近两年的实践，再详细阐述下。

应用拆解

为了实现一个端到端的用户请求，后端服务按照调用链一般可以分成四层

1. 用户接口
   应用作为provider，封装领域服务，提供给外部调用。处理用户命令与展示。这一层的价值在于防止领域模型的泄露。包括提供给本地其他领域调用、rpc调用、前端的http调用。

2. 应用服务
   很薄的一层，主要是面向usecase的。可以协调多个领域服务完成用户接口。

3. 领域服务
   领域服务层，即我们通常说的领域模型。领域内的属性、行为、事件、规则通过领域服务、领域事件、实体、值对象这些有序的组织起来。

4. 基础设施
   应用依赖的外部资源，包括存储、外部接口、消息等。

架构模式

应用被拆成四层，每一层有自己的作用。现在我们需要做的就是有效的组织这四层，以领域模型为中心，合理分层，高内聚、低耦合，隔离并解耦内部核心业务逻辑与外部应用和资源。业界比较常见的有以下几种。

分层架构

左边是传统的四层架构，即还是以调用顺序组织的。右边是依赖倒置的。

所谓依赖倒置即虽然按照运行时的调用关系是A依赖B,但是我在编译环节是让B依赖A。即A提供接口，B来实现。
主要是两点

1. 领域层不再依赖其他任何一层，这样能够实现具体的技术实现不会影响业务，不用纠结到底如何持久化，如何发消息。定义接口，让基础设施层实现。这样可以让领域模型易测试，易维护。
2. 基础层依赖其他各层，包括领域层、接口层、应用服务层。

关于基础设施层是否依赖接口层，这点个人持怀疑态度。从实践来看。基础设施层的迭代频率要低于接口层，抽象程度高于用户接口层。从依赖角度来说，让用户接口层依赖基础设施层更合适。

下图是我们常用的分层架构。

六边形架构

网络用图，如有侵权，联系删除

六边形架构通过内外两个六边形将领域层和其他部分分割成两部分。
对于其他部分，提出了2个概念。

1. 端口(port)
   即应用的入口和出口，是应用同外部交流的唯一通道。一般是以接口的形式存在。端口是在领域服务层。

2. 适配器（adaptor）
   与port相关联。对于入口层（用户接口层）是依赖调用。
   对于出口层（基础设施层)是接口实现的关系。适配器是在非领域层。

举个例子，用户取消支付，系统需要发布消息。
领域层提供入口端口CancelPayService，出口端口sendCancelPayMsg
用户接口层在controller中调用CancelPayService.
基础设施层实现sendCancelPayMsg接口，发送一条消息到kafka。

整洁架构

网络用图，如有侵权，联系删除

整洁架构是在分层架构基础上，更清晰了定义了各层的依赖关系。按照从内到外，定义了各层的重要等级。越往里，代码越核心，依赖就应该越少。外圆依赖内圆，内圆无需感知外圆。

基础设施 -> 用户接口 -> 应用服务 -> 领域服务

菱形对称架构

网络用图，如有侵权，联系删除

菱形架构是去掉了用户接口层和基础设施层这个概念，改成叫网关，同时通过南北网关来区分。

只是换了个说法，本质上没什么区别。

总结

分层、六边形、整洁、菱形架构本质上没什么区别，都是分层。通过不同的维度来把各层关系的依赖关系阐述的更清晰。核心点在于

1. 其他层依赖领域层，领域层不依赖任何外部内容
2. 领域层通过端口与外部交互。
   这两点非常重要，能够帮助开发者专注在领域模型的开发上，而不是纠结与其他层的交互上。

至于其他层是否有明确的依赖关系是次要点，可以忽略。