3分钟大局事件风暴

这篇文章总结了关于大局事件风暴的文章的要点。它还包含有关大局事件风暴后该怎么做的参考！

为什么要举办一场大局事件风暴
我们首先讨论了为什么要举办一场大局事件风暴？我们看到事件风暴是大前期设计和 100% 紧急设计之间的中间路径。当面临软件架构挑战时，评估以下肯定：

• 架构不明显
• 人们有能力应对挑战
• 尽管遵循通常的成功方法，您的进展仍然停滞不前

然后我们研究了如何使活动取得成功。准备和引导对于事件风暴的成功至关重要。

• 如何准备大局事件风暴研讨会告诉我们在开始之前需要准备什么：
  
  • 积极赞助
  • 明确的范围
  • 合适的受众
  • 诱人的邀请
  • 简报致辞。
• 如何为大局事件风暴准备房间列出了研讨会的所有用品：
  
  • 视觉议程
  • 一堵墙
  • 一条长纸条
  • 便利贴
  • 记号笔
  • 一张小桌子
  • 食物。
• 在大局事件风暴开始时要说的话提供了一个可以重复使用的示例。
• 分步指南中确定了运行大局事件风暴的5 个步骤：
  
  1. 生成领域事件
  2. 对它们进行排序
  3. 添加参与者和外部系统
  4. 评书
  5. 逆向讲故事

功能架构
大局事件风暴的主要输出之一是识别有界上下文（功能区域的领域驱动设计）。此上下文地图（功能架构的领域驱动设计）是优化技术投资和让团队有效协作的基石。

• 改善与功能架构愿景草案的协作，详细说明了如何将上下文映射添加到设计中。这篇文章还解释了这如何对整体协作产生巨大影响。
• 决定构建或购买：解释了并非所有有界上下文都具有相同的价值。它还提出了做出合理技术投资决策的促进步骤。例如：“我们应该构建还是购买系统的 X 部分？”。

处理遗留代码
我们建议不要对旧系统进行事件风暴。遗留系统通常不映射到域并且不进行练习。相反，在“事件风暴”中牢记以下三个提示：

• 需要更长的简介来传达与旧系统相关的一些额外背景
• 承认并可视化开发人员因揭幕愿景与现有遗留系统之间的差距而产生的压力。
• 您将需要比平时更多地调整时间表，因为遗留系统会给您带来意想不到的挑战。

进一步的步骤
在事件风暴结束时，所有问题和领域知识都在每个人的脑海中焕然一新。这是解决令人头脑麻木的复杂问题的独特机会。以下是后续活动的一些提示：

• 您应该根据功能或组件来组织您的团队吗？
• 您应该重写或重构有界上下文吗？
• 您如何保护和投资您的皇冠上的珠宝？明确上下文之间的关系，以确保核心领域保持优先级。
• 通过尽早对（微）服务和非功能性需求进行原型设计，避免项目结束时出现重大性能故障。
• 尽早决定要运送什么！
• 通过利用重构技能，尽早交付，同时朝着您的愿景迈进

在大局事件风暴之后，您还可以举办其他研讨会：

• 了解如何通过影响图协作规划软件交付以最大限度地发挥其影响
• 使用用户故事映射来组织您的交付
• 使用Teams 拓扑映射来映射您的理想团队组织
• 使用限界上下文画布获取限界上下文的 360 度视图
• 通过设计级事件风暴在核心上下文上应用更细粒度的领域驱动设计

设计级事件风暴
在这里：您已经绘制了上下文地图并确定了您的核心上下文。您如何最大化并确保您在这些方面的技术投资？事实证明，这就是领域驱动设计的创建目的！