/

手把手教你落地 DDD Part1

01 小传

Domain-Driven Design 是一种开发复杂软件的系统化的 方法学和思想

面向对象方法学还不能很好地应用于企业应用原因:

  • 很多开发人员走了一条只重技术不重业务的弯路。
  • 围绕业务进行开发的方法本身就不好学。
  • 早期面向对象方法学主要考虑的是建模技术,很少考虑协作问题。
  • 难以适应变化。

从业务出发进行系统的设计。

DDD 从面向对象和敏捷中提炼出了一套原则、模式和实践,使面向对象方法学在企业应用中更加容易学习和掌握。

如果没有迭代开发、持续重构、测试驱动、持续集成等敏捷实践的支持,构建良好的领域模型并在代码上落地是很困难的。

微服务是一种架构风格(或者说架构模式)。

02 迭代一

领域专家需要对业务有总体性和本质性的把握,同时对业务发展也要有一定前瞻性,心里要有一盘棋。

捕获行为需求(事件风暴)-> 领域建模 -> 结构设计 -> 数据库设计 -> 代码实现
|------- 模型的建立 --------| |--------- 模型的实现 ------|

03 事件风暴 1

  1. 识别领域事件;在业务流程中发生了什么?
  2. 识别命令;谁,做了什么事,导致领域事件的发生?
  3. 识别领域名词;命令、事件和那些名词性概念有关?

领域事件表示的是,业务流程中每个步骤引发的结果。一般是完成时 + 被动语态。例:订单已被提交。

在 DDD 中的各种命名,一般都优先使用约定俗成的 业务术语

  1. 不要把技术事件当成领域事件。
  2. 查询功能不算领域事件。领域事件应该是对某样事物产生了影响,并被记录的事情。

参加的人,各自写出领域事件 -> 一起讨论,统一理解。这种先发散,后收敛,反复迭代的过程实际上就是一种头脑风暴。“协作”才是事件风暴的精髓。

04 事件风暴 2

References