一文深度解析DDD 领域驱动

迈不过友情╰ 2024-03-22 00:56 81阅读 0赞

在公司对支付业务、结算业务、资金业务使用DDD进行领域建模的两年，得到了许多好评，也面对过不少质疑，总体来说还是能收获不少，这对团队成员理解业务起着很大作用。近半年一直在研究DDD的落地实战，如今已修得阶段性成果，迫不及待与大家分享我的落地经验。

DDD分为**战略设计**与**战术设计**。一般来说，领域建模是属于战略层的，而DDD工程落地是属于战术层的，两者是否结合使用，视实际情况而定，比如传统的MVC架构也能使用DDD进行领域建模，DDD架构最好是先做DDD领域建模。

最新上线的一个微服务——内部交易中心，我们使用了DDD架构来落地，希望看完对大家有启发。

### **工程架构分层理论** ###

在工程落地之前，我们有必要先了解下主流的工程架构或架构思想都有哪些，对这些理论有所了解的，也可以直接跳过看下一个部分。

**1、经典DDD四层架构**

![d61d0270edc9b63f67bcf25d8afe34f4.png][]

在该架构中，上层模块可以调用下层模块，反之不行。即：

*  Interface ——> application | domain | infrastructure
 *  application ——> domain | infrastructure
 *  domain ——> infrastructure

分层作用：

*  用户界面层/表现层：负责向用户显示解释用户命令
 *  应用层：定义软件要完成的任务，并且指挥协调领域对象进行不同的操作。该层不包含业务领域知识
 *  领域层/模型层：系统的核心，负责表达业务概念，业务状态信息以及业务规则。即包含了该领域（问题域）所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上，可以从实体，值对象，聚合（聚合根），领域服务，领域事件，仓储，工厂等方面入手
 *  基础设施层：一是为领域模型提供持久化机制，当软件需要持久化能力时候才需要进行规划；二是对其他层提供通用的技术支持能力，如消息通信，通用工具，配置等的实现；

**2、整洁架构思想**

整洁架构(Clean Architecture)是由Bob大叔在2012年提出的一个架构模型，顾名思义，是为了使架构更简洁。

![f328bf21b52f4784fcdf8ace5eafd1ec.png][]

依赖规则：用一组同心圆来表示软件的不同领域。一般来说，越深入代表你的软件层次越高。外圆是战术是实现机制，内圆的是核心原则。

**这条规则规定软件模块只能向内依赖，而里面的部分对外面的模块一无所知，也就是内部不依赖外部，而外部依赖内部**。同样，在外面圈中使用的数据格式不应被内圈中使用，特别是如果这些数据格式是由外面一圈的框架生成的。

这样做的最大好处是当系统的外部模块不得不改变时（比如，替换已有的过时的数据库系统），系统的内层模块不需要做任何改变。

**3、六边形架构**

六边形架构(Hexagonal Architecture)，又叫做端口适配器模式，是由Alistair Cockburn在2005年提出的。

![312b277b05ef58d88530e18c9e29823b.png][]

六边形架构将系统分为内部（内部六边形）和外部，内部代表了应用的业务逻辑，外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信，端口代表了一定协议，以API呈现。

一个端口可能对应多个外部系统

[d61d0270edc9b63f67bcf25d8afe34f4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/3d0ab1ccef35406fb283a4947441c219.png
[f328bf21b52f4784fcdf8ace5eafd1ec.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/46526c2970e54f628d9c3ec4da2f47da.png
[312b277b05ef58d88530e18c9e29823b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/18/de18f0008ac04760b0b844fcc4158c07.png