设计文档模板：

1. 系统背景和定位
2. 业务需求描述
3. 领域语言整理，主要是整理领域中的各种术语的定义，名词解释
4. 领域划分（分析出子域、核心域、支撑域）
5. 系统用例图
6. 每个子域的领域模型设计（实体、值对象、聚合、领域事件，需要注意的是：领域模型是需要抽象的，要分析业务本质，而不是简单的直接对需求进行建模）
7. 领域模型详细说明（如为什么这样设计的原因、模型内对象的关系、各种业务规则、数据一致性规则等）
8. 领域服务、仓储、工厂设计
9. Saga业务流程设计
10. 关键聚合根的状态流转图
11. 场景走查（讲述如何通过领域模型、领域服务、仓储、Saga流程等完成系统用例以及关键业务流程的）
12. 架构设计（如传统三层架构、经典四层架构、CQRS/ES架构）

一些其他的思考：

• 去除一切花俏的建模技巧，我觉得最重要的方向就是去努力分析问题和事物的本质，针对这个本质进行领域建模。这个领域建模，最主要的还是锻炼的人的事物抽象能力。10个人，建出来的领域模型都不同。本质原因就是大家对同一个问题的理解不同，对事物的本质的理解不同。虽然最终都能解决当前的问题，但是对适应未来需求变化的能力却是不同。
• 所以，我们要把时间花在多理解业务上，让自己成为领域专家，只有这样，才能充分理解业务。多理解一点业务，你才能更好的抽象出业务本质背后的领域模型。很少有人能做到很快理解业务，并很快针对业务设计出正确的领域模型，至少我是不行。
• 领域建模需要时间，是一个迭代的过程，人无完人。而时间很多时候也不会很充足，所以，不太可能一步到位把领域设计做的很完美。我们在整体项目规划的时候可能会有个大的架构设计、业务大图（边界思维），但是不可能达到领域设计的粒度，只能是一期一期的完善，到最后可能才会有完整的上面的目录内容。每一期都需要考虑支持的场景约束、上下文、系统边界、持续集成的相关设计。设计product, not project。