Zen of DDD

  1. 领域划分最好是从场景开始,而不是业务概念
  2. 愿景=》人=》目标=》场景=》小场景,思考顺序大体是这样的,首先要有愿景,然后找出利益相关者,结合目标找出场景。划分好了场景,子域就自然得出。
  3. 场景也就是业务流程如何?可能用到的有用例图和流程图
  4. 要区别问题空间和解空间,不能混为一谈。问题空间里面有业务上下文、域和业务模块、建模等。解空间有限界上下文、实体、聚合等。
  5. 建模会有UML 分析类图或者概念序列图
  6. 划分子域的时候可以先找出单一的抽象层次。然后再进行业务模块划分(业务模块需要自治),子域包括一个或者多个业务模块
  7. 微服务是部署层面的东西,微服务可以包括1个或者多个业务模块,但是不要超过1个子域。
  8. 聚合讲的是不变量,强一致要么是聚合实现要么是领域事件实现,强一致指的是中间结果不会被暴露到外部
  9. 单一职责也是分层级的,有大的单一职责,也有小的单一职责,领域消息不是单一职责
  10. 业务的编排应该在领域层实现而非应用层实现,应用层是很薄的一层。
  11. 我们面对的边界是待开发系统的愿景而不是组织的愿景
  12. 目前实现的DDD大部分缺少业务团队的参与,称之为自嗨型的DDD,较好的实践是“双修”DDD
  13. DDD实操 1. 做好是和业务团队(尤其是产品团队) 一起讨论 2. 目前技术团队可以先做好OO,为后续DDD打下基础。