刚开始在一个项目中使用DDD Big Picture Event Storming可能会很混乱，这里描述一个详细的议程和一个案例简报，保证其在正确的轨道上实行。
每次我参加DDD的Big Picture Event Storming研讨会时，我得到的主要反馈是“这是一次大规模的学习！”。让所需人员在一起几个小时会触发重要的对话。
这就是为什么Big Picture Event Storming非常适合启动新项目的原因。一旦每个人都对问题域了解得足够多，他们就能更好地协同工作 他们可以讨论架构，并起草目标愿景。他们还可以集体讨论团队组织。对于现有系统，他们可以比较不同的迁移策略。例如，重写或重构是否更好？
一旦每个人都对问题域了解得足够多，他们就能更好地协同工作。
更糟糕的是，并非全部。在探索域空间时可能会发生两件事。他们会发现现有的问题。他们还将就领域名某个特定的定义达成一致。这些都是快速获胜的结果。
奇妙的是我们可以在很短的时间内完成所有这些！这是DDD事件风暴的真正力量。在几天之内，我们可以让每个人走上可持续发展的道路，从而实现共同的，足够好的愿景！
在此之前，准备是成功的关键
支持赞助
最重要的事情就是找到好的赞助。通过良好的支持赞助，我的意思是有影响力的人的支持。你想要的是你的工作室成为团队的主动权，而不仅仅是你的主动性。
与这些人进行私人聊天是赢得胜利的最佳方式。最后，您希望他们共享并支持Event Storming会话的共同目标。
范围
有了明确的目标，您应该大致了解会话的范围。DDD Event Storming是一种探索性（而且相当混乱）的活动。不习惯的人一开始会感到有些失落。为了解决这个问题，我发现最好围绕1或2个用例启动研讨会。因此，请与您的赞助商或其他领域专家聊聊，预先提出这些用例。
正如我所说，Event Storming本质上是探索性的。有关这些用例的讨论将在会议期间引起其他问题。由小组决定是否在范围内添加它们。从精确和具体的用例开始是可以的，没有必要害怕错过的东西。
识别第一个领域事件也是一个好主意。它既可以作为一个例子，也可以作为触发事件风暴的一种方式。根据经验，这个事件应该在故事的中间。它也应该足够清楚，让每个人都能理解。例子：
- 交易被预订了
- 订单被支付了
如果您想知道领域活动是什么，请不要担心，我稍后会详细介绍。
听众
现在是列出理想受众的时候了。我发现50％的领域专家和50％的技术人员会话会议效果更好。
由于会议室专家太少，研讨会成为单向教学课程。理想情况下，我们将为您在研讨会范围内预见的所有功能区域提供专家。
我们还需要在研讨会上有相当多的技术人员。最后，这是我们想要发展的领域知识。
请帖
到目前为止，你有了赞助商，一个明确的目标，一些初始用例和理想的受众。接下来要做的就是发送诱人的邀请。这取决于组织，需要或多或少的努力才能让人们参加。
确保在邀请中可以看到赞助商以最大限度地获得支持。例如，请一位有影响力的赞助商为您发送邀请。
简报
当您有最终的与会者名单时，请向他们简要介绍研讨会的目标。这有助于人们在很多方面：
- 要明白这个目标值得他们的时间
- 为最初的迷失方向做好准备
- 了解会话将如何进行
- 获得快速问题的答案
我发现快速的15到30分钟的聚会很有效，但同样，您可能需要适应您的组织。用于书面沟通的群组可能更喜欢电子邮件，聊天或维基。重要的是人们可以提出公共问题并获得答案。
视觉议程
我认为在会议开始前准备有用的一件事是视觉议程。正如我所解释的那样，DDD Event Storming第一次会非常令人不安，人们可能会觉得有点迷茫。在会议开始之前，将不同颜色的便签粘贴在房间的其他墙壁上。与视觉议程一起走过不同步骤的与会者将使他们放心。这也是突出事件风暴的一些规则的好方法。
无限的设计空间
到目前为止，最奇特和最困难的事情是有足够大的墙来做研讨会。Event Storming的发明者Alberto Brandolini建议使用8米长的墙。有2个目标：
- 因空间而不受我们设计的限制
- 有足够的空间让每个人都四处走动和合作
如果你有足够大的房间，这应该是你的第一选择。阿尔贝托说，走廊也是很好的候选人。我对此的经验并不是很成功。当我们尝试它时，参与者抱怨其他人一直来来往往。
一旦你有了房间，你需要一个大的纸卷来粘贴它。这样，您就可以移动您的设计空间。如果您需要延长它，或者如果您决定在工作场所坚持几天，那么您将是安全的。
即时贴
事件风暴消耗了大量便签，特别是领域事件。总而言之，您需要：
- 许多橙色贴在它上面，每人约一堆
- 粉红色
- 大黄色
- 小黄色
- 蓝色
水笔
人们需要在帖子上写一些东西。尖锐或小标记是最好的。它们可以从几米读取，但仍然可以让你在一个帖子上写足够的单词。
没有椅子，没有桌子
典型的会议很无聊，让人昏昏欲睡。相比之下，一个成功的事件风暴研讨会让人们充满活力和富有成效。拆除该区域的椅子和会议桌可以帮助人们保持活力。我们也不希望DDD Event Storming成为一个长期的酷刑会议。因此，我们需要安排足够的休息时间。
在研讨会之前完成了所有准备工作。让我们进入真实的事物。现在我们已准备好一切，我们如何实际开展这个研讨会？
1.准备
- 拆除桌椅
- 将设计空间贴在墙上
- 将视觉议程贴在墙上
- 在某处放下剩下的材料
2.兴奋剂
正如我已经说过的，DDD Event Storming是一种不同类型的架构会议。如果人们没有摆脱他们的传统方式，这将无法奏效。
提高能量水平也非常有用。事件风暴可能非常紧张和累人，所以他们需要所有能量。您可以在funretrospectives.com找到许多强大的物理能量。我和他们中的很多人都取得了成功。
3.简报和议程
现在是时候介绍研讨会了。从目标，范围和用例开始。这是解释我们将要经历的每一步的好时机，以及它们将如何帮助我们实现最终目标。这也是介绍一些一般惯例的好时机。这是我能说的典型简报。
总目标：
请记住，DDD Event Storming是一种将Big Design Up Front缩短几天的方法！它会很激烈，但我们会在很短的时间内做很多事情。
事件风暴可能是混乱的。它可能很崎岖，有时会以意想不到的方式进行，我们可能需要调整。在一天结束时，成功取决于你想要多少！
目标：
本次研讨会的主要成果是领域专家和开发人员之间的共享知识。我们稍后将以此共享知识为基础。
如果我们想要保持这种合作，我们必须坚持使用领域语言。我见过Event Storming会议中进行技术讨论，而不是进行业务领域讨论。
作用域和用例：
今天，我们将在< 您的作用域 > 的范围内工作。为了使事情更具体一点，我们将从这些用例开始< 列出您的用例 >。我们将围绕域事件进行建模，例如< 您的第一个事件 >。
领域事件：
关于便利贴的简要介绍。
橙色便签用于领域事件。以下是< You sample event >的示例。以下几点可帮助您了解哪些域事件：
- 你可以在DDD书籍中了解它们
- 领域专家了解他们
- 用过去时态写出它们是创造有意义事件的一个技巧。它们不是某人或某事的行为（不是“交易者预订交易”）。即使某些事件是由行动引起的，我们对行动也不感兴趣。
- 它们不是技术性的，不应该特定于我们系统的实现
领域定义：（又名无处不在的语言）
每当我们遇到或在一个领域内达成共识时，请随意在大黄色帖子上为其写一个定义。这是一种构建共享领域词汇表的方法。这对改善我们所有人之间的沟通非常有帮助。这反过来又改善了我们在许多不同方面的工作方式（例如：在选择重构时）。
问题：
同样，我们使用紫色便签来解决“问题”。每当我们遇到：
- 我们无法回答的问题
- 一些似乎不对的东西
- 或者我们应该研究的任何问题
将它记录在紫色的即时贴上。
最后，为了保持步伐可持续发展，我们每50分钟休息5分钟。
4. 领域事件生成
这是研讨会实际开始的时候。要求与会者在用例的上下文中抓住他们可以想到的任何领域事件。为了帮助他们开始，请首先从您事先准备的域事件开始。
在某些时候，你会发现域事件生成的速度会下降。这表明是时候进入下一阶段了。第一阶段通常足够25分钟左右。
5.排序
在第二阶段，我们将要求他们按时间顺序对事件进行排序。这个想法是代表设计板上的典型工作流程。在生成阶段，人们正在写下他们可以想到的任何事件，这需要他们各自独自工作。在这个阶段，他们需要彼此交谈以对事件进行排序。
这就是DDD Event Storming的神奇之处。与会者都对系统有不同的看法。他们在设计板上实现了一些领域事件。他们需要通过这些差异来讨论事件的排序。
当人们尝试对所有领域事件进行排序时，事件风暴会发挥其魔力。
这一阶段应引发激烈的讨论。希望该小组能够捕获许多领域定义和问题。
您可以根据需要随意组织流程表示法：通常情况下，泳道将出现替代品，垂直对齐将表示分支。当发生某种循环时，您可能还会创建重复的即时贴。
6.Actor和外部系统
你已经开始写下你的系统的故事了。所有好故事都有英雄！这一次，请与会者确定触发或响应事件的Actor（有角色的人）。惯例是使用小黄色即时贴。没有必要为每个事件添加一个actor，在一个事件链的开头粘贴一个就足够了。
同样，复杂系统也与外部系统交互。外部系统可以不是操作人员，可以是例如在线API。交互表示是使用蓝色即时贴用于外部系统，将事件放置在与其交互的位置。
(banq注：这两个阶段类似UML的用例图和顺序图阶段)
7.讲故事
现在是时候检查整个画面是否有意义。自人类开始以来，故事一直是知识的载体。过去的知识通过篝火故事代代相传。我们的大脑很难听，记住并理解故事。
如果人们害怕单独做这些事情，可以寻找一些志愿者。然后请第一位志愿者讲述系统的故事。他只需要按时间顺序完成事件并解释会发生什么。
正如叙述者所说，观众会提出问题并注意到不一致。这也是添加，删除或替换事件以修复故事的时候了。可能会出现一些额外的定义。如果在会话期间问题看起来太大而无法修复，请将其置于粉红色问题后。
叙述故事可能会非常累人，所以请新的叙述者在某个时候接管。
(banq注：故事注重逻辑顺序)
8.反向讲故事
为了在域中进行更深入的深入研究，可以采用反向讲故事的方式。再找几个志愿者，让他们从最后讲出这个故事。其实是反复询问“可能引发此事件的原因是什么？”。这将生成或更新事件，Actor或外部系统。
这种方法运作良好的原因是问题触发了我们大脑的创造性部分。我们可以想象各种新的可能性。这个阶段非常高效，并带来了很多见解。
9.结束
就是这样，你已经到了DDD Big Picture Event Storming的末尾。在这一点上，安顿下来并评估结果是个好主意。
到目前为止，DDD Big Picture Event Storming的最大成果是对该领域更好的共享理解。
您可能真的想知道可交付成果是什么。此时，大多数可交付成果都是无形资产：
- 到目前为止，最大的是对领域的更好的共享理解。这将通过改善协作来节省大量时间。它将避免规范错误，并实现更好的设计。
- 总之，你已经发现了问题。解决这些问题可能是获得高回报的快速胜利。
- 这些定义是统一语言的第一块砖。利用它可以节省时间并保持系统的概念完整性。
- 最后，这也是协作架构的必要步骤。对领域的良好共享理解使得关于功能架构的讨论成为可能。
因此，接下来的步骤可以是：
- 解决一个主要问题。Alberto Brandolini在书中回忆起这种情况。实际上，Big Boss已经停止了所有其他工作，直到他们解决了一个“新”问题。
- 通过添加和改进定义来继续发展无处不在的统一语言
- 为了起草目标架构，做更多的研讨会。
EventStorming解锁起草架构，绘制团队和可持续的重构路径。
点击标题见原文系列。