Skip to main content

开始事件风暴

Event-Driven architecture 事件驱动架构

前提:#

  1. 确保所有关键人员（业务和技术利益相关者）都在同一个房间内
  2. 在一个时间轴上使用域事件为整个业务流建模

第一天 【Running a Big Picture Workshop】#

  1. 每个人将业务流程的关键领域事件写在橙色的便利贴上，用动词过去时，并根据纸卷上的时间轴放置它们

  2. 这些信息是至关重要的，所以我尝试捕获每一个警告标志，并把它们写在紫色的大感叹号上，然后我把它们放在新兴工作流程的相应步骤附近【标记待探讨的问题】

  3. 我们开始提到外部系统：它们可以是外部组织或服务，或在线应用程序。我开始用更大的粉色粘贴来表示软件必须处理的外部系统

第二天#

  1. 是时候更深入地了解的系统的核心组件的机制：我们开始引入
    • 命令代表用户意图/行动/决定他们是蓝色粘贴，eg:下单、发送、邀请，
    • 演员（小黄色粘贴）为特定的用户类别
  2. 它们大多以“Whenever ”这个词开头。这类似于“每当超过给定的阈值，
    • eg: 每当用户从新设备登录，我们会给他发送短信警告”。
    • eg: 每当用户注册完，我们会给他发送一封欢迎邮件。
    • 淡紫色是在一个事件之后发生的反应逻辑，并触发命令。“Policy”是我们在这个特定研讨会中使用的名称。
    • 策略捕获了我们流程的反应逻辑，通常我们可以口头描述方式： Whenever [event(s)] then [command(s)]
    • 当涉及到策略时，因为在事件和反应之间总是有一个业务决策。有时，潜在的决定太明显，不容注意；强制性的淡紫色只是为了迫使你的建模团队思考。
  3. 聚合(淡黄色)：责任驱动。考虑有界上下文，【聚合并非按照时间轴排列，但事件更聚合】

疑惑点解答：#

1.只有少数地方仍然看起来像crud，但大多数业务都是用系统中的领域事件根据时间线描述的

2.有一些命令看起来就像对相应域事件的重新表述【这不是一个问题，并非所有的是一对一关系】

事件风暴介绍标志#

我们期望进程从一个给定的触发器（通常是一个命令或一个外部事件）开始，并以一个事件和读取模型的组合结束。