分析与建模-事件风暴

2024-05-24 16:16:58   3  举报





事件风暴是一种以协作探索复杂业务领域为目标的，灵活的工作坊（workshop）形式的活动。它有不同的玩法，适用于多种不同的场景： 1. 发掘现有的健康业务线中最有改进价值的地方。 2. 探索新业务模式的可行性。 3. 设想新的服务，为每个参与方带来最好的正向结果。 4. 设计整洁可维护的事件驱动型（Event-Driven）软件，以支持快速发展的业务。事件风暴的适应性，决定了它允许有不同背景的项目干系人进行复杂的，跨学科的沟通交流，提供了一种跨越信息孤岛和专业界限的新型协作方式。

事件风暴

领域驱动设计

DDD

业务全景分析

作者其他创作

大纲/内容

热点

策略

执行

用户

读模型

申请

贷款申请已审批

参与者

触发

写模型

贷款申请

满足规则

决策命令

审批人

步骤

关键元素

说明

第一步：识别事件

事件

1. 领域事件是过去发生的与业务有关的事实。 2. 领域事件具有时间的特征，所有事件连接起来会形成明显的时间轴。 3. 领域事件是管理者和运营者重点关心的内容，若缺少该事件，会对管理与运营产生影响。 4. 领域事件会导致目标对象状态的变化。 5. 技术事件和查询功能都不算领域事件.

第一步：标识热点

在识别下事件的过程中，若有以下情况，可以为事件标记热点： 1. 暂不算的事件流分支。 2. 出现分歧和争执的事件。 3. 需要强调的事件或事件对应的领域逻辑。

第二步：识别参与者

1. 角色：触发事件的人。 2. 策略：角色事件的规则，通常是随着时间的推移，满足规则要求的时间条件后会自动触发事件。 3. 外部系统：由当前系统外的其他系统触发事件。 4. 事件：即当前事件的前置事件，在事件风暴中无需表示。

第三步：识别限界上下文

限界上下文

1. 纵向：识别事件流中的事件，倘若相领两个事件之间的关系较弱，或者体现了两个非常明显的阶段，就可以对其进行分割。 2. 横向：梳理所有的事件，根据组成事件的名词和动词去发现事件之间的相关性（相同、相似的名称），然后去提炼一个整体的概念。原则：单一抽象层次原则，正交原则，奥卡姆剃刀原则。

第四步：识别上下文映射

映射关系

1. 首先识别跨限办上下文之间相邻事件的关系。 2. 事件之间是否存在直接触发的关系（参与者为前置事件），需要确定这两个事件所述的限界上下文。 3. 判断这两个事件所属的限界上下文，谁是主要的，主要的BC就是下游。通常，前置事件为下游，或者是事件的发布者。

第五步：领域分析建模

事件的起因，除了外部系统是直接发布事件之外，无论是用户活动，还是满足某个条件，都需要一个命令来响应，它才是直接导致事件发生的“因”。在事件风暴中，将命令称之为“决策命令”，决策命令往往由动宾短语组成。

写模型就是状态发生了变化的目标对象。正是写模型状态的变更才导致了事件被触发。一旦写模型的状态发生变更，就会触发事件，因为事件是状态变更产生的事实。这意味着该由写模型承担发布事件的职责，因为只有它才具备侦知状态是否变更以及何时变更的能力。

参与者执行决策命令时，要如何才能变更写模型的状态呢？很明显，需要结合业务场景为参与者提供充足的信息，参与者才能做出正确的决策。业务场景为参与者提供的信息在事件风暴中被称之为“读模型（Read Model）”。读模型拥有的信息可以由参与者通过读（查询）操作获得。在业务场景中，读模型为参与者提供恰如其分的决策信息。读模型是用户执行决策命令必需的输入信息，在代码层面，读模型就是执行决策命令领域行为所需的输入参数。

用户征信

外部系统

审批贷款申请

变更状态

触发命令

提供信息

审批失败处理