一不小心，你可能会被事件风暴冲昏头脑，犯下这些新手错误！
以下是具有技术背景的人特别容易犯的两个反模式错误！
- 不幸的是，这些错误可能会让一个成功的 "事件风暴 "研讨会变成一个失败的计划，让参与者尝到苦头。
- 幸运的是，这两种反模式很容易避免！因此，请记住它们，一切都会顺利！
错误1：继续参加研讨会，直到完成大型前期设计
事件风暴是一种设计活动。与任何设计活动一样，我们可能会把它推得太远。您可以随时对您的设计进行改进。您可以花费数周时间对所有子域进行详细的设计级事件风暴分析并填充边界上下文画布。
如果这样做，您就又回到了 "前期大设计 "的老路：把时间和精力花在设计活动上，而不是通过构建和调整来学习更多知识。事件风暴并不是另一种进行 "先期大设计 "的方法。事件风暴法的优势在于创建粗略的 "先期设计"。
将研讨会时间间隔化，并采用 "移动脚手架 "方法，会取得更好的效果：
- 为研讨会设定一个时限--不要超过两个整天！大事件风暴通常需要一天时间，您可以在第二天开展后续活动。
- 起草足够的草案，以便开始工作
- 有所建树
- 从中学习
- 重复
错误 2：谈论领域驱动设计（又称 DDD）
事件风暴（Event Storming）和事件驱动架构（Event-Driven Architecture）源自领域驱动设计（Domain Driven Design）社区。领域驱动设计是构建可靠软件系统的最强大工具之一。然而......它也充满了晦涩难懂的概念和外来行话！
在进行深入研究领域驱动设计（DDD）概念的设计级事件风暴法（Design-Level Event Storming）时，问题尤其突出。对于不了解 DDD 的人来说，从这种级别的事件风暴开始可能是一个太大的挑战。
您应该这样做：
- 如果可以，请用与会者更熟悉的同义词替换 DDD 关键字--例如，用 "功能区"（Functional area）代替 "边界上下文"（Bounded Context）。您可以快速向精通 DDD 的参与者提及 DDD 名称。
- 如果找不到满意的同义词，可在研讨会期间根据需要逐一慢慢引入 DDD 关键字和概念。
- 从 "大事件风暴 "开始。这可以让人们熟悉一些 DDD 概念。
- 之后再深入学习设计级事件风暴法
总结
当您走进事件风暴室时，请记住这两种反模式。每当您发现自己正在做其中一项事情时，请停下来！如果您是主持人，您还可以在研讨会开始时提醒参与者这两个陷阱。最后，无论您是主持人还是参与者，如果您觉得研讨会正在走向这些错误，请举手并表达您的担忧！