可落地的DDD-工程结构

Posted 方丈的寺院

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了可落地的DDD-工程结构相关的知识,希望对你有一定的参考价值。

背景

几年前我在可落地的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. 领域层通过端口与外部交互。
    这两点非常重要,能够帮助开发者专注在领域模型的开发上,而不是纠结与其他层的交互上。

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

以上是关于可落地的DDD-工程结构的主要内容,如果未能解决你的问题,请参考以下文章

可落地的DDD-工程结构

可落地的DDD-工程结构

可落地的DDD-如何利用DDD进行微服务的划分

可落地的DDD-如何利用DDD进行微服务的划分

DDD 领域驱动设计落地实践系列:工程结构分层设计

跨越DDD从理论到工程落地的鸿沟