一不小心，你可能會被事件風暴衝昏頭腦，犯下這些新手錯誤！
以下是具有技術背景的人特別容易犯的兩個反模式錯誤！
- 不幸的是，這些錯誤可能會讓一個成功的 "事件風暴 "研討會變成一個失敗的計劃，讓參與者嚐到苦頭。
- 幸運的是，這兩種反模式很容易避免！因此，請記住它們，一切都會順利！
錯誤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 概念。
- 之後再深入學習設計級事件風暴法
總結
當您走進事件風暴室時，請記住這兩種反模式。每當您發現自己正在做其中一項事情時，請停下來！如果您是主持人，您還可以在研討會開始時提醒參與者這兩個陷阱。最後，無論您是主持人還是參與者，如果您覺得研討會正在走向這些錯誤，請舉手並表達您的擔憂！