烂翻译系列之学习领域驱动设计——第十二章：事件风暴

In this chapter, we will take a break from discussing software design patterns and techniques. Instead, we will focus on a low-tech modeling process called EventStorming. This process brings together the core aspects of domain-driven design that we covered in the preceding chapters.

在本章中，我们将暂时不讨论软件设计模式和技术。相反，我们将专注于一种称为“事件风暴”的低技术建模过程。这个过程融合了我们在前面章节中讨论过的领域驱动设计的核心方面。

You will learn the EventStorming process, how to facilitate an EventStorming workshop, and how to leverage EventStorming to effectively share domain knowledge and build a ubiquitous language.

您将学习事件风暴过程，如何组织事件风暴研讨会，以及如何利用事件风暴有效地共享领域知识并构建通用语言。

What Is EventStorming?

事件风暴是什么？

EventStorming is a low-tech activity for a group of people to brainstorm and rapidly model a business process. In a sense, EventStorming is a tactical tool for sharing business domain knowledge.

事件风暴是一种低技术活动，供一群人进行头脑风暴并快速建模业务流程。从某种意义上说，事件风暴是分享业务领域知识的一种战术工具。

An EventStorming session has a scope: the business process that the group is interested in exploring. The participants are exploring the process as a series of domain events, represented by sticky notes, over a timeline. Step by step, the model is enhanced with additional concepts—actors, commands, external systems, and others—until all of its elements tell the story of how the business process works.

事件风暴研讨会有一个范围：即团队想要探索的业务流程。与会者将流程视为一系列领域事件，这些事件由便利贴表示，并在时间线上展示。逐步地，模型会加入其他概念——如行为者、命令、外部系统等——直到模型的所有元素都讲述了业务流程是如何运作的。

Who Should Participate in EventStorming?

谁应该参加事件风暴？

Just keep in mind that the goal of the workshop is to learn as much as possible in the shortest time possible. We invite key people to the workshop, and we don’t want to waste their valuable time.—Alberto Brandolini, creator of the EventStorming workshop

请记住，研讨会的目标是在尽可能短的时间内学到尽可能多的东西。我们邀请关键人物参加研讨会，我们不想浪费他们宝贵的时间。——事件风暴研讨会的创始人 Alberto Brandolini

Ideally, a diverse group of people should participate in the workshop. Indeed, anyone related to the business domain in question can participate: engineers, domain experts, product owners, testers, UI/UX designers, support personnel, and so on. As more people with different backgrounds are involved, more knowledge will be discovered.

理想情况下，参加研讨会应该是一个多样化的群体。事实上，任何与业务领域相关的人都可以参与: 工程师、领域专家、产品所有者、测试人员、 UI/UX 设计人员、支持人员等等。随着越来越多不同背景的人参与其中，会发现更多的知识。

Take care not to make the group too big, however. Every participant should be able to contribute to the process, but this can be challenging for groups of more than 10 participants.

不过，要注意不要让这个群体过于庞大。每个与会者都应该能够为这个过程做出贡献，但对于超过10名参与者的团队来说，这可能是一个挑战。

What Do You Need for EventStorming?

你需要什么来组织事件风暴？

EventStorming is considered a low-tech workshop because it is done using a pen and paper—a lot of paper, actually. Let’s see what you need in order to facilitate an EventStorming session:

事件风暴被认为是一种低技术研讨会，因为它使用笔和纸——实际上是很多纸来进行。让我们看看您需要准备什么来组织一次事件风暴研讨会：

Modeling space    建模空间

       First, you need a large modeling space. A whole wall covered with butcher paper makes the best modeling space, as shown in Figure 12-1. A large whiteboard can fit the purpose as well, but it has to be as big as possible—you will need all the modeling space you can get.

       首先，您需要一个大的建模空间。覆盖着牛皮纸的一整面墙是最佳的建模空间，如图12-1所示。一个大的白板也可以达到这个目的，但是它必须尽可能的大——你需要所有你能得到的建模空间。

Sticky notes    便签

       Next, you need lots of sticky notes of different colors. The notes will be used to represent different concepts of the business domain, and every participant should be able to add them freely, so make sure you have enough colors and enough for everyone. The colors that are traditionally used for EventStorming are described in the next section. It’s best to stick to these conventions, if possible, to be consistent with all of the currently available EventStorming books and trainings.

       接下来，你需要大量的不同颜色的便利贴。这些便利贴将用于表示业务领域的不同概念，每个与会者都应该能够自由添加便利贴，所以请确保你有足够的颜色和数量供每个人使用。传统上用于事件风暴的颜色将在下一节中描述。如果可能的话，最好遵循这些约定，以保持与所有现有的事件风暴书籍和培训的一致性。

Markers   记号笔

       You’ll also need markers that you can use to write on the sticky notes. Again, supplies shouldn’t be a bottleneck for knowledge sharing—there should be enough markers for all participants.

       你还需要一些马克笔，以便在便利贴上写字。同样，物资不应该是知识分享的瓶颈——应该为所有与会者提供足够的马克笔。

Snacks    零食

       A typical EventStorming session lasts about two to four hours, so bring some healthy snacks for energy replenishment.

       典型的事件风暴研讨会持续大约两到四个小时，所以带一些健康的零食来补充能量。

Room    场地

       Finally, you need a spacious room. Ensure there isn’t a huge table in the middle that will prevent participants from moving freely and observing the modeling space. Also, chairs are a big no-no for EventStorming sessions. You want people to participate and share knowledge, not sit in a corner and zone out. Therefore, if possible, take the chairs out of the room.

       最后，你需要一个宽敞的房间。确保房间中间没有一张大桌子阻碍与会者自由移动和观察建模空间。同样，椅子是事件风暴研讨会的大忌。你希望人们参与并分享知识，而不是坐在角落里走神。因此，如果可能的话，把椅子从房间里搬走。

Figure 12-1. Modeling space for EventStorming

图12-1. 事件风暴的建模空间

The EventStorming Process

事件风暴过程

An EventStorming workshop is usually conducted in 10 steps. During each step, the model is enriched with additional information and concepts.

事件风暴研讨会通常分为10个步骤进行。在每个步骤中，模型都会增加额外的信息和概念。

Step 1: Unstructured Exploration

第 1 步：非结构化探索

EventStorming starts with a brainstorm of the domain events related to the business domain being explored. A domain event is something interesting that has happened in the business. It’s important to formulate domain events in the past tense (see Figure 12-2)—they are describing things that have already happened.

事件风暴首先对与正在探索的业务域相关的领域事件进行头脑风暴。领域事件是业务中发生的有趣事情。用过去式表述领域事件是很重要的（参见图12-2）——它们描述的是已经发生的事情。

Figure 12-2. Unstructured exploration

图12-2.  非结构化探索

During this step, all participants are grabbing a bunch of orange sticky notes, writing down whatever domain events come to mind, and sticking them to the modeling surface.

在这一步中，所有与会者都会拿起一堆橙色的便利贴，写下脑海中出现的任何领域事件，并将它们贴在建模表面上。

At this early stage, there is no need to worry about ordering events, or even about redundancy. This step is all about brainstorming the possible things that can happen in the business domain.

在这个早期阶段，不需要担心事件的顺序，甚至不需要担心冗余。这一步主要是为了集思广益，思考在业务领域中可能发生的事情。

The group should continue generating domain events until the rate of adding new ones slows significantly.

团队应该持续生成领域事件，直到添加新事件的速度明显减慢。

Step 2: Timelines

第2步：时间线

Next, the participants go over the generated domain events and organize them in the order in which they occur in the business domain.

接下来的步骤是，与会者回顾已经产生的领域事件，并将它们按照在业务领域中发生的顺序进行排列。

The events should start with the “happy path scenario”: the flow that describes a successful business scenario.

事件应该从“顺利路径场景”开始：描述成功业务场景的流程。

Once the “happy path” is done, alternative scenarios can be added—for example, paths where errors are encountered or different business decisions are taken. The flow branching can be expressed as two flows coming from the preceding event or with arrows drawn on the modeling surface, as shown in Figure 12-3.

一旦“顺利路径”完成，就可以添加其他场景——例如，遇到错误或采取不同业务决策的路径。流程分支可以表示为从前一个事件分出的两个流程，或者在建模表面上绘制箭头，如图12-3所示。

Figure 12-3. Flows of events

图12-3.  事件流

This step is also the time to fix incorrect events, remove duplicates, and of course, add missing events if necessary.

这一步也是修正错误事件、删除重复的事件以及（如果必要的话）添加缺失事件的时机。

Step 3: Pain Points

第 3 步：痛点

Once you have the events organized in a timeline, use this broad view to identify points in the process that require attention. These can be bottlenecks, manual steps that require automation, missing documentation, or missing domain knowledge.

一旦你将事件按照时间线组织好，就可以利用这种全局视图来识别流程中需要关注的要点。这些可能是瓶颈、需要自动化的手动步骤、缺失的文档或缺失的领域知识。

It’s important to make these inefficiencies explicit so that it will be easy to return to them as the EventStorming session progresses, or to address them afterward. The pain points are marked with rotated (diamond) pink sticky notes, as illustrated in Figure 12-4.

将这些效率低下的问题明确化是很重要的，以便随着事件风暴研讨会的进行，可以轻松地回到这些问题上来，或者在之后解决它们。痛点用旋转的（菱形）粉红色便利贴标记，如图12-4所示。

Figure 12-4. A diamond-shaped pink sticky note, which points to an aspect of the process that requires attention: missing domain knowledge about how the airfare prices are compared during the booking process

图12-4.  一个菱形的粉红色便利贴，指向流程中需要关注的方面：在预订过程中缺少关于如何比较机票价格的领域知识。

Of course, this step is not the only opportunity to track pain points. As a facilitator, be aware of the participants’ comments throughout the process. When an issue or a concern is raised, document it as a pain point.

当然，这一步并不是追踪痛点的唯一机会。作为引导者，请在整个过程中留意与会者的评论。当提出问题或关注点时，将其记录为痛点。

Step 4: Pivotal Events

第4步：关键事件

Once you have a timeline of events augmented with pain points, look for significant business events indicating a change in context or phase. These are called pivotal events and are marked with a vertical bar dividing the events before and after the pivotal event.

一旦你得到了包含痛点的事件时间线，寻找表明上下文或阶段变化的重要业务事件。这些被称为关键事件，并用一条垂直线标记，以区分关键事件之前和之后的事件。

For example, “shopping cart initialized,” “order initialized,” “order shipped,” “order delivered,” and “order returned” represent significant changes in the process of making an order, as shown in Figure 12-5.

例如，“shopping cart initialized（购物车初始化）”、“order initialized（订单初始化）”、“order shipped（订单发货）”、“order delivered（订单交付）”和“order returned（订单退货）”表示了订单生成过程中的重大变化，如图12-5所示。

Figure 12-5. Pivotal events denoting context changes in the flow of events

图12-5.  表示事件流中上下文变化的关键事件

Pivotal events are an indicator of potential bounded context boundaries.

关键事件是潜在的有界上下文边界的指示器。

Step 5: Commands

第5步：命令

Whereas a domain event describes something that has already happened, a command describes what triggered the event or flow of events. Commands describe the system’s operations and, contrary to domain events, are formulated in the imperative. For example:

领域事件描述已经发生的事件，而命令描述了是什么触发事件或事件流。命令描述了系统的操作，与领域事件相反，命令是以命令的形式表达的。例如:

• Publish campaign    发布广告（宣传）活动
• Roll back transaction    回滚事务
• Submit order    提交订单

Commands are written on light blue sticky notes and placed on the modeling space before the events they can produce. If a particular command is executed by an actor in a specific role, the actor information is added to the command on a small yellow sticky note, as illustrated in Figure 12-6. The actor represents a user persona within the business domain, such as customer, administrator, or editor.

命令写在浅蓝色的便利贴上，并放在它们可以产生的事件之前的建模空间上。如果特定的命令是由具有特定角色的行为者执行的，则将行为者信息添加到该命令上的小黄色便利贴上，如图12-6所示。行为者代表业务领域内的用户角色，如客户、管理员或编辑。

Naturally, not all commands will have an associated actor. Therefore, add the actor information only where it’s obvious. In the next step we will augment the model with additional entities that can trigger commands.

当然，并非所有命令都有相关联的行为者。因此，只在明显需要时才添加行为者信息。接下来，我们将使用可以触发命令的其他实体来扩充模型。

Figure 12-6. The “Submit Order” command, executed by the customer (actor) and followed by the “Order initialized,” “Shipping cost calculated,” and “Order shipped” events

图12-6.  由消费者（行为者）执行的“ Submit Order（提交订单）”命令，接下来是“ Order initialization（订单初始化）”、“ Shipping Cost Calculated（运费计算）”和“ Order Shipping（订单发货）”事件

Step 6: Policies

第6步：策略

Almost always, some commands are added to the model but have no specific actor associated with them. During this step, you look for automation policies that might execute those commands.

几乎总是会有一些命令被添加到模型中，但它们没有与之关联的特定行为者。在这一步中，你寻找可能会执行这些命令的自动化策略。

An automation policy is a scenario in which an event triggers the execution of a command. In other words, a command is automatically executed when a specific domain event occurs.

自动化策略是一种场景，场景中一个事件触发命令的执行。换句话说，当特定的领域事件发生时，命令将自动执行。

On the modeling surface, policies are represented as purple sticky notes connecting events to commands, as shown by the “Policy” sticky note in Figure 12-7.

在建模表面上，策略用紫色的便利贴表示，将事件与命令连接起来，如图12-7中的“策略”便利贴所示。

Figure 12-7. An automation policy that triggers the “Ship Order” command when the “Shipment Approved” event is observed

图12-7.  当观察到“Shipment Approved（发货已批准）”事件时，触发“Ship Order（发货订单）”命令的自动化策略

If the command in question should be triggered only if some decision criteria is met, you can specify the decision criteria explicitly on the policy sticky note. For example, if you need to trigger the escalate command after the “complaint received” event, but only if the complaint was received from a VIP customer, you can explicitly state the “only for VIP customers” condition on the policy sticky.

如果正在讨论的命令只有在满足某些决策条件时才会触发，那么您可以在策略便签上明确地指定决策条件。例如，如果您需要在“complaint received（收到投诉）”事件之后触发“escalate（升级）”命令，但仅当投诉来自VIP客户时，才能在策略便签上显式地声明“仅适用于 VIP 客户”条件。

If the events and commands are far apart, you can draw an arrow on the modeling surface to connect them.

如果事件和命令相隔较远，你可以在建模表面上画一条箭头来连接它们。

Step 7: Read Models

第7步：读模型

A read model is the view of data within the domain that the actor uses to make a decision to execute a command. This can be one of the system’s screens, a report, a notification, and so on.

读模型是行为者用来决定执行命令的领域内的数据视图。这可以是系统的一个屏幕、一个报告、一个通知，等等。

The read models are represented by green sticky notes (see the “Shopping cart” note in Figure 12-8) with a short description of the source of information needed to support the actor’s decision. Since a command is executed after the actor has viewed the read model, on the modeling surface the read models are positioned before the commands.

读模型由绿色的便利贴表示（参见图12-8中的“购物车”便利贴） ，它简短描述了支持行为者决策所需的信息源。由于命令是在行为者查看了读模型之后执行的，所以在建模图面上，读模型位于命令之前。

 

Figure 12-8. The view of the “Shopping cart” (read model) needed for the customer (actor) to make their decision to submit the order (command)

图12-8.  顾客（行为者）在做出提交订单（命令）的决策时所需的“Shopping cart（购物车）”（读取模型）视图

Step 8: External Systems

第8步：外部系统

This step is about augmenting the model with external systems. An external system is defined as any system that is not a part of the domain being explored. It can execute commands (input) or can be notified about events (output).  

这一步是关于使用外部系统来扩充模型的。外部系统被定义为不属于正在探索的领域的任何系统。它可以执行命令（输入）或接收事件通知（输出）。

The external systems are represented by pink sticky notes. In Figure 12-9, the CRM (external system) triggers execution of the “Ship Order” command. When the shipment is approved (event), it is communicated to the CRM (external system) through a policy.

外部系统用粉红色的便利贴表示。在图12-9中，CRM（外部系统）触发“Ship Order”（发货订单）命令的执行。当发货被批准（事件）时，它会通过一个策略通知CRM（外部系统）。

Figure 12-9. External system triggering execution of a command (left) and approval of the event being communicated to the external system (right)

图12-9.  外部系统触发命令的执行（左）以及将事件批准通知给外部系统（右）

By the end of this step, all commands should either be executed by actors, triggered by policies, or called by external systems.

在这一步结束时，所有命令应该要么由行为者执行，要么由策略触发，要么由外部系统调用。

Step 9: Aggregates

第9步：聚合

Once all the events and commands are represented, the participants can start thinking about organizing related concepts in aggregates. An aggregate receives commands and produces events.

一旦所有事件和命令都被表示出来，与会者就可以开始考虑将相关概念组织成聚合。聚合接收命令并产生事件。

Aggregates are represented as large yellow sticky notes, with commands on the left and events on the right, as depicted in Figure 12-10.

如图12-10所示，聚合用大型的黄色便利贴表示，左侧是命令，右侧是事件。

Figure 12-10. Commands and domain events organized in an aggregate

图12-10.  以聚合形式组织的命令和领域事件

Step 10: Bounded Contexts

第10步：有界上下文

The last step of an EventStorming session is to look for aggregates that are related to each other, either because they represent closely related functionality or because they’re coupled through policies. The groups of aggregates form natural candidates for bounded contexts’ boundaries, as shown in Figure 12-11.  

事件风暴研讨会的最后一步是寻找相互关联的聚合，这可能是因为它们表示了密切相关的功能，或者是因为它们通过策略耦合在一起。这些聚合群组形成了自然的有界上下文边界的候选者，如图12-11所示。

Figure 12-11. A possible decomposition of the resultant system into bounded contexts

图12-11.  将结果系统分解为有界上下文的一种可能

Variants

变体

Alberto Brandolini, the creator of the EventStorming workshop, defines the EventStorming process as guidance, not hard rules. You are free to experiment with the process to find the “recipe” that works best for you.

事件风暴研讨会的创始人 Alberto Brandolini 将事件风暴过程定义为指导，而不是硬性规则。您可以自由地尝试这个过程，以找到最适合您的“配方”。

In my experience, when introducing EventStorming in an organization I prefer to start by exploring the big picture of the business domain by following steps 1 (chaotic exploration) through 4 (pivotal events). The resultant model covers a wide range of the company’s business domain, builds a strong foundation for ubiquitous languages, and outlines possible boundaries for bounded contexts.

根据我的经验，在组织中引入事件风暴时，我更喜欢首先通过遵循步骤1（混乱探索）到步骤4（关键事件）来探索业务领域的大致情况。所得到的模型涵盖了公司业务领域的广泛范围，为通用语言打下了坚实的基础，并勾勒了有界上下文的可能边界。

After gaining the big picture and identifying the different business processes, we continue to facilitate a dedicated EventStorming session for each relevant business process—this time, following all the steps to model the complete process.

在获得了整体情况并确定了不同的业务流程后，我们继续为每个相关的业务流程组织专门的事件风暴研讨会——这一次，我们将遵循所有步骤来模拟完整的流程。

At the end of a full EventStorming session, you will have a model describing the business domain’s events, commands, aggregates, and even possible bounded contexts. However, all of these are just nice bonuses. The real value of an EventStorming session is the process itself—the sharing of knowledge among different stakeholders, alignment of their mental models of the business, discovery of conflicting models, and, last but not least, formulation of the ubiquitous language.

在完整的事件风暴研讨会结束时，您将拥有一个描述业务领域的事件、命令、聚合甚至可能的有界上下文的模型。然而，所有这些都只是很好的额外收获。事件风暴研讨会的真正价值在于过程本身——不同利益相关者之间的知识共享，他们对企业心理模型的调整、冲突模型的发现，以及最后但同样重要的是，通用语言的形成。

The resultant model can be adopted as a basis for implementing an event-sourced domain model. The decision of whether to go that route or not depends on your business domain. If you decide to implement the event-sourced domain model, you have the bounded context boundaries, the aggregates, and of course, the blueprint of the required domain events. 

结果模型可以作为实现基于事件源（event-sourced）的领域模型的基础。是否选择这条路线取决于你的业务领域。如果你决定实现基于事件源的领域模型，你将拥有有界上下文的边界、聚合，当然还有所需领域事件的蓝图。

When to Use EventStorming

何时使用事件风暴

The workshop can be facilitated for many reasons:

举办研讨会的原因有很多:

Build a ubiquitous language    建立一种通用语言

       As the group cooperates in building the model of the business process, they instinctively synchronize the terminology and start using the same language.

      当团队合作构建业务流程模型时，他们本能地同步术语并开始使用相同的语言。

Model the business process    为业务流程建模

       An EventStorming session is an effective way to build a model of the business process. Since it is based on DDD-oriented building blocks, it is also an effective way to discover the boundaries of aggregates and bounded contexts. 

       事件风暴研讨会是构建业务流程模型的有效方法。由于它基于面向 DDD 的构建块，因此它也是发现聚合和有界上下文边界的有效方法。

Explore new business requirements    探索新的业务需求

       You can use EventStorming to ensure that all the participants are on the same page regarding the new functionality and reveal edge cases not covered by the business requirements.

       你可以使用事件风暴来确保所有与会者对新功能有相同的理解，并揭示业务需求未涵盖的边界情况。

Recover domain knowledge    找回领域知识

       Over time, domain knowledge can get lost. This is especially acute in legacy systems that require modernization. EventStorming is an effective way to merge the knowledge held by each participant into a single coherent picture.

       随着时间的推移，领域知识可能会丢失。这在需要现代化的遗留系统中尤为突出。事件风暴是一种有效的方法，可以将每个与会者所掌握的知识合并成一幅连贯的图画。

Explore ways to improve an existing business process    探索改进现有业务流程的方法

       Having an end-to-end view of a business process provides the perspective needed to notice inefficiencies and opportunities to improve the process.

       对业务流程的端到端视图提供了必要的视角，以发现流程中的低效率以及改进流程的机会。

Onboard new team members    新团队成员加入

       Facilitating an EventStorming session together with new team members is a great way to expand their domain knowledge. 

       与新团队成员一起组织事件风暴研讨会，是扩展他们领域知识的好方法。

In addition to when to use EventStorming, it’s important to mention when not to use it. EventStorming will be less successful when the business process you’re exploring is simple or obvious, such as following a series of sequential steps without any interesting business logic or complexity.

       除了何时使用事件风暴外，什么时候不应该使用它也是值得提及的。当你所探索的业务流程很简单或显而易见时，如遵循一系列顺序步骤而没有任何有趣的业务逻辑或复杂性时，事件风暴的效果可能会较差。

Facilitation Tips

便利贴

When facilitating an EventStorming session with a group of people who have never done EventStorming before, I prefer to start with a quick overview of the process. I explain what we are about to do, the business process we are about to explore, and the modeling elements we will use in the workshop. As we go through the elements—domain events, commands, actors, and so on—I build a legend, depicted in Figure 12-12, using the sticky notes we will use and labels to help the participants remember the color code. The legend should be visible to all participants during the workshop.

在与一群从未做过事件风暴的人组织事件风暴研讨会时，我倾向于首先快速概述一下这个过程。我解释我们将要做什么，我们将要探索的业务流程，以及我们在研讨会中将使用的建模元素。当我们浏览这些元素——领域事件、命令、行为者等——时，我会用我们将使用的便利贴和标签构建一个图例，如图12-12所示，以帮助与会者记住颜色代码。图例在研讨会期间应该对所有与会者可见。

Figure 12-12. Legend depicting the various elements of the EventStorming process written on the corresponding sticky notes

图12-12.  图例描述了写在相应便利贴上的事件风暴过程的各种元素

Watch the Dynamics

观察动态变化

As the workshop progresses, it’s important to track the energy of the group. If the dynamics are slowing down, see whether you can reignite the process by asking questions or whether it’s time to advance to the next stage of the workshop.

随着研讨会的进行，跟踪团队的活力很重要。如果活力下降，看看是否可以通过提问来重新点燃这个过程，或者是否应该进入研讨会的下一个阶段。

Remember that EventStorming is a group activity, so ensure that it is handled as such. Make sure everyone has a chance to participate in the modeling and the discussion. If you notice that some participants are shying away from the group, try to involve them in the process by asking questions about the current state of the model.

请记住，事件风暴是一种团队活动，因此要确保将其作为团队活动进行处理。确保每个人都有机会参与建模和讨论。如果你注意到一些与会者正在回避这个团队，试着通过询问当前模型状态的问题来让他们参与进来。

EventStorming is an intense activity, and at some point, the group will need a break. Don’t resume the session until all the participants are back in the room. Resume the process by going through the current state of the model to return the group to a collaborative modeling mood.

事件风暴是一项严肃紧张的活动，在某时，团队需要休息一下。在所有与会者回到房间之前不要继续研讨会。通过回顾模型的当前状态来恢复这个过程，从而使团队回到协作建模的氛围中。

Remote EventStorming

远程事件风暴

EventStorming was invented as a low-tech activity in which people interact and learn together in the same room. The creator of the workshop, Alberto Brandolini, has often objected to conducting EventStorming remotely because it’s impossible to achieve the same levels of participation, and hence, collaboration and knowledge sharing, when the group is not colocated.  

事件风暴最初是作为一项低技术含量的活动被发明的，在这种活动中，人们在同一房间内互动和学习。研讨会的创始人阿尔贝托·布兰多利尼（Alberto Brandolini）经常反对远程进行事件风暴，因为当团队不在一起时，不可能达到同样的参与度，因此也无法实现协作和知识共享。

However, with the onset of the COVID-19 pandemic in 2020, it became impossible to have in-person meetings and do EventStorming as it was meant to be done. A number of tools attempted to enable collaboration and facilitation of remote EventStorming sessions. At the time of this writing, the most notable of them is miro.com. Be more patient when doing online EventStorming and take into account the less effective communication that results.

然而，随着2020年新冠疫情的爆发，面对面开会和按照原本方式进行事件风暴变得不可能。许多工具试图实现远程事件风暴研讨会的协作和推动。在撰写本文时，其中最值得注意的是miro.com。在进行在线事件风暴时，请更加耐心，并考虑到由此产生的沟通效果会较差。

In addition, my experience shows that remote EventStorming sessions are more effective with a smaller number of participants. While as many as 10 people can attend an in-person EventStorming session, I prefer to limit online sessions to five participants. When you need more participants to contribute their knowledge, you can facilitate multiple sessions, and afterward compare and merge the resultant models.

此外，我的经验表明，与会者数量较少的远程事件风暴研讨会更为有效。虽然最多可以有10人参加面对面的事件风暴研讨会，但我更喜欢将在线研讨会限制与会者在5名以内。当您需要更多与会者贡献他们的知识时，您可以组织多次研讨会，并在之后比较和合并结果模型。

When the situation allows, return to in-person EventStorming.

当条件允许时，恢复面对面的事件风暴。

Conclusion

总结

EventStorming is a collaboration-based workshop for modeling business processes. Apart from the resultant models, its primary benefit is knowledge sharing. By the end of the session, all the participants will synchronize their mental models of the business process and take the first steps toward using a ubiquitous language. 

事件风暴是一种基于协作的建模业务流程研讨会。除了产生的模型外，它的主要好处是知识共享。在研讨会结束时，所有与会者都会同步他们对业务流程的心理模型，并迈出使用通用语言的第一步。

EventStorming is like riding a bicycle. It’s much easier to learn by doing it than to read about it in a book. Nevertheless, the workshop is fun and easy to facilitate. You don’t need to be an EventStorming black belt to get started. Just facilitate the session, follow the steps, and learn during the process.

事件风暴就像骑自行车一样。通过实践来学习要比在书本上学习更容易。不过，这种研讨会既有趣又易于推动。你不需要是事件风暴的高手就可以开始。只要推动研讨会，按照步骤进行，并在过程中学习。

Exercises

练习

1. Who should be invited to an EventStorming session?     应该邀请哪些人参加事件风暴研讨会？

a. Software engineers    软件工程师

b. Domain experts    领域专家

c. QA engineers    质量控制工程师

d. All stakeholders having knowledge of the business domain that you want to explore    所有拥有您想要探索的业务领域知识的利益相关者

答案：d。

2. When is it a good opportunity to facilitate an EventStorming session?    什么时候是组织事件风暴研讨会的好时机？

a. To build a ubiquitous language.    为了建立通用语言。

b. To explore a new business domain.    为了探索新的业务领域。

c. To recover lost knowledge of a brownfield project.    为了找回待重新开发项目遗失的知识。

d. To introduce new team members.    有新团队成员加入。

e. To discover ways to optimize the business process.    为了发现优化业务流程的方法。

f. All of the above answers are correct.    以上所有答案都是正确的。

答案：f。

3. What outcomes can you expect from an EventStorming session?    你期望从事件风暴研讨会得到什么成果？

a. A better shared understanding of the business domain    对业务领域有更好的共同理解

b. A strong foundation for a ubiquitous language    为通用语言奠定坚实的基础

c. Uncovered white spots in the understanding of the business domain    在理解业务领域时发现的盲点

d. An event-based model that can be used to implement a domain model    一个基于事件的模型，可用于实现领域模型

e. All of the above, but depending on the session’s purpose    上述所有内容，但取决于研讨会的目的

答案：e。All the answers are possible outcomes of an EventStorming session. The outcome you should expect to get depends on your initial purpose for facilitating the session.    所有答案都是事件风暴研讨会可能的结果。你期望得到的结果取决于你最初推动研究会的目的。

---

1 Of course, that’s not a hard rule. Leave a few chairs if some of the participants find it hard to be on their feet for so long.      当然，这并不是一条硬性规定。如果一些与会者发现自己很难站立这么长时间，那就放几把椅子。