什么是领域驱动设计

什么是DDD

DDD, 即Domain-Driven Design，就是领域驱动设计的缩写。它是一种根据领域专家的输入对软件进行建模以匹配该领域的软件设计方法。
它主要是为了构建复杂领域，将业务的复杂性和技术的架构的实现解耦开来。DDD并不是一种具体的架构，而是一种方法论，通过边界的划分方法构建出清晰的领域和应用边界，让架构更加容易的进行演进。

核心概念

• 值对象： 简单来说就是没有ID但是需要了解上下文的东西。例如，当我们在外面吃饭的时候，在餐厅里面选位子落座，我们会关心这个桌子是哪里生成的，编码是什么以及规格是怎样的吗？显然不会，有空位坐就可以了。当然我们还是需要关注值对象上下文的，如刚才的例子，我们消费者并不关心坐哪个位子，但是商家是关心的，因为他要根据桌号来进行上菜以及收账。
• 实体：必须有ID的东西，他具有延续性。例如，人的身份证，户口变迁身份证的ID 不会变。
• 聚合：聚合就是有业务关联关系的实体以及值对象的集合，通过实体、值对象以及各自之间的业务逻辑聚合在一起完成某个业务节点，我们就可以理解为聚合。比如公司里面的人，组成的各个部门就是聚合。
• 聚合根：聚合根的核心作者用就是保证有一个数据输入修改的统一入口来保证聚合内的数据修改统一的符合聚合中的业务规则。聚合根是一种特殊的实体, 他的作用就是协调实体和对象实现逻辑功能。

核心思想

领域驱动设计，核心就是根据领域进行拆分。领域： 当然这里的领域就是说具体的业务领域，例如制药、环境、建筑、金融等。总体的原则就是将原来的复杂的问题，拆分成多个单独的多个问题进行求解。

拆分方法

那拆分的具体原则是什么呢？ 怎么合理怎么拆分，有点类似于初高中做数学题画的辅助线， 就是怎么合适怎么来。

上面感觉有点废话，是不是还是不明白怎么拆

当然也有一种最常见的拆分思路，就是从战略维度和战术维度两个维度进行拆分：

• 战略设计：主要从业务角度出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，实现业务领域模型的构建
• 战术设计：不同于战略设计的高屋建瓴，战术设计是从实际的技术角度出发，它更加侧重于领域模型的技术实现，按照领域模型完成微服务的开发以及落地。

实现过程

实现 DDD 落地大致需要经历这样三个阶段，即为业务分析-》战略设计-》战术设计，不同阶段的输出都是下一阶段的输入。

• 业务分析：整体系统的第一阶段， 需要联合领域专家、设计和开发一起梳理梳理清楚业务事件、业务逻辑和业务分类。
• 战略设计：使用统一的语言，对业务进行领域划分，并且进行领域建模，并且在建模的过程中需要梳理出值对象、实体和聚合。
• 战术设计：以战略设计的分层结果作为输入。

总结

领域驱动设计从2004年首次被提出，很难很短篇幅将整体DDD说的特别清楚。其中还有六边形架构、洋葱架构、整洁架构等出现，一直出有很多的新概念和衍生概念的出现，整个思想也在不断被完善。 本文主要是让大家对于DDD有一个整体的了解。整体对我们的启发，尤其是团队的项目负责同学而言，需要从整个项目整体全局触发，系统性考虑问题的新思路吧。

参考

标题	URL
What’s DDD	https://www.youtube.com/watch?v=pMuiVlnGqjk
领域驱动设计简洁	https://dunwu.github.io/design/architecture/%E9%A2%86%E5%9F%9F%E9%A9%B1%E5%8A%A8%E8%AE%BE%E8%AE%A1.html#ddd-%E7%AE%80%E4%BB%8B
领域驱动设计	https://dunwu.github.io/design/architecture/%E9%A2%86%E5%9F%9F%E9%A9%B1%E5%8A%A8%E8%AE%BE%E8%AE%A1.html
一文看懂DDD领域驱动设计	https://modelbaba.com/architecture/ddd/2100.html
DDD 领域驱动设计落地实践系列：战略设计和战术设计	https://xie.infoq.cn/article/81beef783e361f0ba6a0ca67a