最近很火的DDD(领域驱动设计)，在微服务中怎么使用？

Posted 2021-05-01 技术领导力

    许多朋友给挨踢哥留言，想深入学习DDD，以及如何在微服务设计中应用。本文先来探讨DDD。

什么是DDD？
    DDD的全称为Domain-driven Design，即领域驱动设计。下面我从领域、问题域、领域模型、设计、驱动这几个词语的含义和联系的角度去阐述DDD是如何融入到我们平时的软件开发初期阶段的。要理解什么是领域驱动设计，首先要理解什么是领域，什么是设计，还有驱动是什么意思，什么驱动什么。

    领域建模的基础是要先理解领域，让自己成为领域专家。如果做到了这点，我们就打好了坚实的基础了。但是，有时一个领域往往太复杂，涉及到的领域概念、业务规则、交互流程太多，导致我们没办法直接针对这个大的领域进行领域建模。所以，我们需要将领域进行拆分，本质上就是把大问题拆分为小问题，然后各个击破的思路。然后既然把一个大的领域划分为了多个小的领域（子域），那最关键的就是要理清每个子域的边界；然后要搞清楚哪些子域是核心子域，哪些是非核心子域，哪些是公共支撑子域；然后，还要思考子域之间的联系是什么。

如何实践DDD？

    那么，我们该如何划分子域呢？从业务相关性的角度去思考，也就是我们平时说的按业务功能为出发点进行划分。还是拿经典的电商系统来分析，通常一个电商系统都会包含好几个大块，比如：

• 会员中心：负责用户账号登录、用户信息的管理；

• 商品中心：负责商品的展示、导航、维护；

• 订单中心：负责订单的生成和生命周期管理；

• 交易中心：负责交易相关的业务；

• 库存中心：负责维护商品的库存；

• 促销中心：负责各种促销活动的支持；

  
  

    上面这些中心看起来很自然，因为大家对电子商务的这个领域都已经非常熟悉了，所以都没什么疑问，好像很自然的样子。所以，领域划分是不是就是没什么挑战了呢？

    显然不是。之所以我们觉得子域划分很简单，是因为我们对整个大领域非常了解了。如果我们遇到一个冷门的领域，就没办法这么容易的去划分子域了。这就需要我们先去努力理解领域内的知识。

    当我们不了解一个东西的时候，如何去拆解它？当我们对整个领域有一定的熟悉了，了解了领域内的相关业务的本质和关系，我们就自然而然的能划分出合理的子域了。

    不过并不是所有的系统都需要划分子域的，有些系统只是解决一个小问题，这个问题不复杂，可能只有一两个核心概念。所以，这种系统完全不需要再划分子域。但不是绝对的，当一个领域，我们的关注点越来越多，每个关注点我们关注的信息越来越多的时候，我们会不由自主的去进一步的划分子域。比如，也许我们一开始将商品和商品的库存都放在商品中心里，但是后来由于库存的维护越来越复杂，导致揉在一起对我们的系统维护带来一定的困难时，我们就会考虑将两者进行拆分，这个就是所谓的业务垂直分割。

    通过上面介绍的细化子域的内容，现在再来谈该如何领域建模，就方便很多了。主要方法是：

    划分好边界上下文，通常每个子域（sub domain）对应一个边界上下文（bounded context），同一个边界上下文中的概念是明确的，没有任何歧义；
在每个边界上下文中设计领域模型，具体的领域模型设计方法有很多种，如以场景为出发点的四色原型分析法；这个步骤最核心的就是找出聚合根，并找出每个聚合根包含的信息；
    画出领域模型图，圈出每个模型中的聚合边界；
    设计领域模型时，要考虑该领域模型是否满足业务规则，同时还要综合考虑技术实现等问题，比如并发问题；领域模型不是概念模型，概念模型不关注技术实现，领域模型关心；所以领域模型才能直接指导编码实现；
思考领域模型是如何在业务场景中发挥作用的，以及是如何参与到业务流程的每个环节的；
    场景走查，确认领域模型是否能满足领域中的业务场景和业务流程；
模型持续重构、完善、精炼；

领域模型的核心作用：

• 抽象了领域内的核心概念，并建立概念之间的关系；

• 领域模型承担了领域内的状态的维护；

• 领域模型维护了领域内的数据之间的业务规则，数据一致性；

    下图是一个普通电商系统的商品中心的领域模型图，给大家参考：

技能延伸

    需要特别注意的是，领域模型设计只是整个软件设计中的很小一部分。除了领域模型设计之外，要落地一个系统，我们还有非常多的其他设计要做，比如：

• 容量规划

• 架构设计

• 数据库设计

• 缓存设计

• 框架选型

• 发布方案

• 数据迁移、同步方案

• 分库分表方案

• 回滚方案

• 高并发解决方案

• 一致性选型

• 性能压测方案

• 监控报警方案

    作为一个合格的开发人员或架构师，除了要会DDD领域驱动设计，还要会上面这么多的技术能力，确实是非常不容易的。所以，千万不要以为会DDD了就以为自己很牛逼，实际上你会的只是软件设计中的冰山一角而已。

---

精彩文章推荐：

• 
  

• 
  

• 
  

• 
  

•