上一篇我们讲了DDD的基本概念，包含DDD的定义，使用场景和使用误区。这一篇将继续讲在项目中如果想进行DDD设计，我们的主要流程都有哪些

一、主要流程一览

DDD的主要流程 - 图1
注：图片引用自张逸老师的领域驱动实践https://gitbook.cn/gitchat/column/5cdab7fb34b6ed1398fd8de7/topic/5cdabf6434b6ed1398fd8e5c

  • 先启阶段
    • 确定利益相关人
    • 制订先启计划
    • 确定业务期望与愿景
    • 优先级权衡
    • 对问题域的共同理解
    • 确定业务范围
    • 确定业务流程
  • 战略设计
    • 业务用例分析
    • 事件风暴
    • 确定架构方式
    • 限界上下文识别
    • 限界上下文协作方式确定
  • 战术设计
    • 确定类图
    • 确定聚合，值对象及类之间的关系
    • 确定聚合根及聚合范围
    • 确定应用服务，领域服务，聚合根，仓储等组件之间的调用关系
  • 优化迭代
    • 反向优化类图
    • 反向优化限界上下文

      二、先启阶段

      此阶段主要是为后续所有阶段，确定一些基本的共识和原则，作为后续遇到问题时进行处理的依据。需要达成的共识和原则如下：
  1. 业务期望与愿景，对问题的共同理解，用于指导战略设计时，区分业务的重要程度和业务价值，用于评估和确定子域的划分，将子域划分为核心子域（Core Domain），支撑子域，通用子域
  2. 业务范围，业务流程，用于确定后续哪些功能需要实现，需要与哪些其他系统进行对接，功能之间的协作关系
  3. 优先级权衡原则，用于确定在整个开发过程中的资源调度和业务实现优先级的确定
  4. 建立初步的统一语言，对于核心流程和核心业务形成统一语言

    三、战略设计

  • 问题域方面：此阶段通过对上一阶段识别出来的业务流程和业务范围进行细化，可以通过业务用例分析或者事件风暴进行细化。然后从整体业务流程中，识别出场景的紧密和松散处，紧密的放在同一个限界上下文（Bounded Context）中，松散处则作为限界上下文划分时的边界，同时考虑各限界上下文映射（Context Map）（不能出现循环关系，只能是单向的），让每一个限界上下文实现一个自治的业务价值，在达到垂直的业务重用的同时，满足上下文内可以根据业务的变化而演变，但不影响其他上下文的目的，以限制一次变更引起的变更范围。
  • 架构方面：根据整体的业务认识确定架构方式，比如是单体架构还是微服务架构，比如是各自独享数据库还是服务间可共享数据库等，通过分层构架来隔离关注点，尤其是将领域实现独立出来，能够更利于领域模型的单一性与稳定性；引入六边形架构可以清晰地表达领域与技术基础设施的边界；通过领域事件来异步触发业务规则并且对不同限界上下文进行解耦。

DDD的主要流程 - 图2

四、战术设计

DDD的主要流程 - 图3

  1. 确定类图：在战略设计已经确定的整体架构下，针对具体要实现的限界上下文，分析限界上下文的业务流程，画出实现类和实现类之间的关系
  2. 在类图上区分出聚合，值类型，聚合根以及聚合范围。
  3. 场景拆分：拆分限界上下文需要实现的业务流程中的场景，针对每一个场景进行细化，确定应用服务，领域服务，聚合根，仓储等之间的调用关系

  4. 开发落地：通过测试驱动开发方式，先根据场景拆分后的需要，编写测试用例，再实现业务。重复此过程，直接场景中的所有业务场景均实现完成

    五、迭代优化

  5. 通过在实现过程中，发现一些之前未发现的业务概念，业务规则等，需要补充到统一语言中。

  6. 将一些不再使用的概念从代码和统一语言中删除
  7. 将新的概念反映到新的实现类图中，完善类图，并重新考虑类之间的协作关系
  8. 随着业务的发展，可能发现一些上下文之间的划分不是很合理，可能有些原本关系不密切的上下文，随着业务发展越来越紧密，需要合并。也可能一个上下文随着业务的发展，越来越复杂，需要拆分为多个上下文，需要在发现这些情况时，反过来调整战略设计中的上下文划分，并进一下调整实现代码

这一篇讲了DDD的主要流程，是一个迭代的过程，从建立共识，确定业务期望，范围到战略战术设计，项目落地，反向迭代优化之前的设计结果。下面我们详细讲一下先启阶段的每个具体步骤的注意事项，点击传送门前往。