深入了解EventStorming：概念、应用与实践指南

### 深入了解 EventStorming：概念、应用与实践指南 #### 1. 理解 EventStorming EventStorming 是一种强大的技术，但在使用时，一些先入为主的观念，如基于现有的组织边界来定义结构，可能会对工作坊中定义的结构产生偏差。相反，运用关键事件等技术让结构自然浮现，更有可能揭示出不受错误假设影响的理想领域边界。 在某些情况下，混乱式探索并非合适的方法。例如远程会议，由于难以在远程环境中重现混乱式探索和并行对话，此时可以采用单线程模式，即仅由一人将事件添加到时间轴上，其他参与者进行引导。在面对面的工作坊中，当氛围不够活跃或需要控制工作坊方向时，也可使用单线程模式。 EventStorming 是一种为协作和学习而优化的技术。很多人可能会因它缺乏精确的符号和规范而感到困惑，比如有人会觉得时间轴上的事件层次不一致，有些过于笼统，有些又过于详细。但我们要明白，时间轴上的内容是人们将个人知识汇聚成集体知识的一种方式，是交流的基础。如果时间轴的某些部分更详细，可能是因为人们认为聚焦某些领域更有价值，也可能是因为对那些定义不明确领域有深入了解的人未参加工作坊。墙上的便利贴只是促进交流、分享知识和发现改进机会的道具，不必过于纠结活动结束后的成果或复用价值，但可以拍照记录并将重要的学习成果提炼成其他形式。 #### 2. 何时使用 EventStorming 掌握 EventStorming 意味着能够应对各种场景。在构建架构现代化愿景时，它有助于探索领域的各个部分，以确定现代化的机会或验证现有的业务领域现代化提案。 例如，在一个电商客户项目中，我们需要为现代化的初始阶段寻找合适的业务领域。我们确定了四个候选领域，但还需要更多信息来做出最终选择。于是我们开展了 EventStorming 会议，在对其中一个领域进行分析后，很快排除了它。深入了解该领域后，我们发现不同子领域之间存在大量依赖关系，现代化该领域需要五个团队参与并涉及五个代码库，对于初始阶段来说，挑战和风险太大。 EventStorming 在定义领域和子领域方面表现出色，因为它代表了来自不同视角的集体领域知识。只要确保关键人员参与工作坊，我们就能有很高的信心基于领域的所有关键细节来划分领域边界，而不会遗漏重要假设。后续还可以结合其他技术，如领域消息流建模和团队拓扑结构，从多个角度评估和优化这些边界，以确保设计能实现理想的现代化成果。 EventStorming 有不同的应用类型，包括大图景、流程建模和软件设计 EventStorming。大图景模式适用于在大面积范围内进行混乱式探索和团队学习；流程建模可用于以更高的粒度和更规范的符号来映射较小的领域，适合描绘当前状态和设计新的或改进的流程；软件设计 EventStorming 则增加了更多的结构和细节，是连接领域和高度契合领域的软件的重要步骤。 #### 3. 行业实例：公司聚会上的 EventStorming 2021 年，一家自疫情开始后首次进行面对面聚会的公司联系我们，希望我们为他们在德国农场举办的公司聚会开展一个工作坊。我们同意进行一次 EventStorming 会议。当天，参会人员来自五个团队，还有客户成功团队成员甚至会计人员。会议充满了讨论点，大家围绕影响多个团队的话题展开了很多交流，开始建立联系并发现新的机会。 在会议中，我们开始探索领域边界，并讨论公司在发展阶段应如何组织。其中一个有趣的时刻是，当我们一起讨论时间轴时，我指着一个代表边缘情况（即一个 bug）的事件，问一位开发者该问题出现的频率，他认为这不是常见问题，无需花费时间处理。但此时客户成功团队的成员加入讨论，指出这是一个相当常见的错误，当天上午就有两位用户报告了此类问题。 这就是 EventStorming 会议的典型情况，在日常工作中，我们往往对业务的运行方式存在很多错误假设和误解。通过将不同背景的人聚集在一起，我们可以创造一个学习和纠正误解的空间，从而在日常工作中做出更好的决策。 会议结束时，我们进行了一场精彩的展示，沿着时间轴描述业务的运作方式以及不同产品的配合情况。人们不断参与和退出讨论，以澄清观点并补充细节。有一个团队提到要构建一个 API 来解决提出的问题，但另一个团队表示他们已经有了满足需求的 API。当天晚上，这两个团队就一起实现了调用该 API 的代码，解决了当天提出的问题。 这个案例表明，EventStorming 能够创造一个有价值的交流和学习空间。即使没有明确的目的，将多个团队聚集在一起进行 EventStorming 会议也可能带来许多积极的成果。虽然难以