DDD

事件风暴

事件

每次用户操作、业务活动留下来的不可磨灭的足迹，它牵涉到状态的迁移，业务事实的发生，忠实地记录了每次执行命令后可能产生的结果。

命令

在一个业务场景中，一系列关键的事件会连接起来，会形成明显的额基于一条时间线的状态迁移过程。这种状态迁移过程体现了业务的因果关系。这种因果关系是一种不断传递的过程，导致事件发生的因我们称之为命令。

拓展：
事件由命令触发，命令的发起者是参与者，参与者将对事件的分析与业务场景结合起来，参与者不再发起一个业务流程，而是应该做出决策。决策就是命令，通常需要由如下两个方面的数据作为支撑：

1、信息：必须基于足够充分的信息才能做出正确的决策，提供这些信息的对象就称之为读模型（Read Model），在事件风暴中用绿色标签表示。
2、策略：一旦做出决策就会触发一个业务流程，流程的执行暗含了业务规则，该规则被命名为策略，在事件风暴中用紫色标签表示。

描述策略的时候往往使用“一旦”这个关键字引导对策略规则的描述。策略引发的决策可以是自动的。

识别事件

1、由用户活动触发：如用户将商品加入到购物车；
2、外部系统：支付系统返回交易凭证；
3、时间消逝导致：订单的支付时间超时；
4、另一个领域事件的结果：支付命令产生支付完成事件，该事件导致订单完成事件；

语言描述：

1. 当…
2. 如果发生…
3. 当…的时候请通知我
4. 发生…时

聚合

聚合是命令的真正发起者，这是相对于参与者而言。在问题域中我们以参与者的角度去触发事件，但是在领域模型中我们应该以解决方案域，从职责的角度看待命令。如在电商系统中，问题域为买家购买了商品，对应的解决方案域则是购物车添加了商品。分析可获得“购物车”这个聚合。

领域建模

1、挑选任意一个与用户有关的事件，反向驱动出决策命令，该用户就是发出决策命令的人（角色）。

2、根据决策命令与事件之间的因果关系，推导出要发布该事件必须的前置信息，即决策所需的读模型。读模型通常由用户通过查询操作获得，可以理解为是决策命令行为的输入参数。

3、根据事件状态变更的目标，决定决策命令与事件之间的聚合对象。若无法确定，则保留一个空的黄色即时贴，待以后确定。

4、选择当前事件的后置事件。若后置事件仍然与用户有关，则重复第一步；若后置事件与外部系统有关，可以跳过该事件的建模，继续选择下一个后置事件。若事件与策略有关，在进一步细化策略对象之后，驱动出决策命令，重复第三步。

案例

以信用卡开卡事件流为例，我们依次选择以下三个事件：

1、“开卡申请已审批”事件，推断决策命令，“审批开卡申请”；
2、根据决策推导出触发事件需要的读模型。申请和征信；
3、分析中间的聚合对象，事件和决策将会影响到申请状态；
4、找到了聚合对象申请状态。

5、选择下一个事件“卡号已生成”，推导出它的决策命令为生成卡号。
6、该事件同时和策略相关，则读模型为“卡号规则”；
7、识别两者直接按的聚合对象，卡号的生成影响了信用卡的属性，音系目标对象为“信用卡”；

8、进行下一步，后置事件为“信用卡已经制作完毕”，由于改事件由外部系统发布，可以忽略建模过程，仅仅标记外部系统；

本文参考：
事件风暴的设计要素与驱动力