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打下基础。