01 小传
Domain-Driven Design 是一种开发复杂软件的系统化的 方法学和思想。
面向对象方法学还不能很好地应用于企业应用原因：
- 很多开发人员走了一条只重技术不重业务的弯路。
- 围绕业务进行开发的方法本身就不好学。
- 早期面向对象方法学主要考虑的是建模技术，很少考虑协作问题。
- 难以适应变化。
从业务出发进行系统的设计。
DDD 从面向对象和敏捷中提炼出了一套原则、模式和实践，使面向对象方法学在企业应用中更加容易学习和掌握。
如果没有迭代开发、持续重构、测试驱动、持续集成等敏捷实践的支持，构建良好的领域模型并在代码上落地是很困难的。
微服务是一种架构风格（或者说架构模式）。
02 迭代一
领域专家需要对业务有总体性和本质性的把握，同时对业务发展也要有一定前瞻性，心里要有一盘棋。
捕获行为需求（事件风暴）-> 领域建模 -> 结构设计 -> 数据库设计 -> 代码实现 |
03 事件风暴 上
- 识别领域事件；在业务流程中发生了什么？
- 识别命令；谁，做了什么事，导致领域事件的发生？
- 识别领域名词；命令、事件和那些名词性概念有关？
领域事件表示的是，业务流程中每个步骤引发的结果。一般是完成时 + 被动语态。例：订单已被提交。
在 DDD 中的各种命名，一般都优先使用约定俗成的 业务术语。
- 不要把技术事件当成领域事件。
- 查询功能不算领域事件。领域事件应该是对某样事物产生了影响，并被记录的事情。
参加的人，各自写出领域事件 -> 一起讨论，统一理解。这种先发散，后收敛，反复迭代的过程实际上就是一种头脑风暴。“协作”才是事件风暴的精髓。
04 事件风暴 下
- 首先我们看看领域事件的作用。从代码实现的角度来看，领域事件一般会对应一段代码逻辑，这段逻辑可能会最终改变数据库中的数据。另外，在事件驱动的架构中，一个领域事件可能会表现为一个向外部发送的异步消息。
- 那命令的作用体现在哪儿呢？领域建模时，我们可以通过对命令的走查（walkthrough），细化和验证领域模型。在实现层面，一个命令可能对应前端的一个操作，例如按下按钮；对于后端而言，一个命令可能对应一个 API。
- 再来说命令的执行者。在领域建模时，执行者可能本身就是一个领域对象，也可能是领域对象充当的角色，或者是权限管理中的一个角色。
如果要体现严格的时间顺序，我们可以用流程图、用顺序图等方法，但事件风暴不必关注这一点。
我们是把每个小步骤都当作独立的一个事务来看待，还是把它们合起来作为同一个事务。另外，可以设想，如果每个小步骤都向外界发出一个领域事件，对系统后续的功能是不是有意义。原则上宜粗不宜细。
抓住协作、统一语言、识别领域名词等要点。
事件风暴是一种通过协作的方式捕获行为需求的方法，在这个过程里，业务人员和技术人员一起消化领域知识、形成统一语言、并为领域建模奠定基础。
References
–