學習 Event Storming 事件風暴的感想
學習 Event Storming 的一點感想 前言 近幾年，工作坊非常流行，也順便分享我的感想。 先說明，Event Storming 的初始概念非常棒，小編也從不排斥各種軟體開發的方法論與流程，但在接觸了 Event Storming 後，對於軟體開發的初心者來說，當中可能有兩個小陷阱。 Event Storming 最近一直在看 Event Storming ，也曾聽聞有人說用事件風暴來取代 UML Methodology，但 UML 充其量只是個 Methodology，你又不是導入 RUP，所以我特別強調這個 XDD，那麼..言歸正傳、的確，事實上我是同意一項軟體產品所需要的領域知識往往是跨團隊的，沒有任何單一團隊可以掌握它的全貌，但要如何媒合不同背景知識的人做有效溝通非常的困難，所以即便是求討論會議除了需要各利害關係人參與之外、客戶能加入討論更能釐清許多需求認知的問題、避免走過多冤枉路，UML 各個圖形的繪製也必須是團隊一同繪製、而不是單一個 Member 來繪製，因為對於商業流程的理解、包含名詞的使用、團隊有共識需使用客戶端的專有名詞與語言。 看完 Event Storming 我倒認為重點不在於 Event Storming，透過 Event Storming 確實很容易找出商業流程的核心價值、風險、與機會，但注意了，我覺得這裡有一個小陷阱就是，重點是在於〔團隊 與 多方角色 所進行討論的『這一個過程』中，便利貼只是風暴過程中的工具而已〕。 我們進行需求討論的的『多方討論』即是邀請任何有興趣的人、也不用限制討論範圍，但這裡還有第二個陷阱，在討論特定功能流程 Process Modeling 時，當你有了 Command、Event、Actor、System、Policy 或 Read Model... 等，準備進行 Software Design 軟體設計時，這裡我非常推崇 Aggregate 與 Bounded Context 等概念，因為這算是 OOA(Object Oriented Analysis) / OOD(Object Oriented Design) 的缺陷部分（OOAD 不是沒有缺陷、近期學習 DDD 時我發現可以補足 OOAD 不足之處），但我要講的第二個小陷阱是，當你在進行 Software Design 時，仍
