一文深度解析DDD 领域驱动

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

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

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

工程架构分层理论

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

1、经典DDD四层架构

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

• Interface ——> application | domain | infrastructure
• application ——> domain | infrastructure
• domain ——> infrastructure

分层作用：

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

2、整洁架构思想

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

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

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

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

3、六边形架构

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

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

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