前言

前面我們花了兩天的時間說明Event Driven Architecture的概念，跟Request Driven不同的地方在哪裡，也初步說了EDA由三個conponent所構成的。

今天原本想要講publisher和subscriber的模式，突然發現有人問我Event Storming是EDA的一種模式嗎？

我當下就震驚！？((O.o

後來仔細想想，會搞混很正常，兩者的核心概念都在Event，只是發展跟應用的地方不一樣。

今天就先跟大家分享什麼是Event Storming吧! pub-sub留到明天再說。

好～讓我們開始吧!!

Event Storming

Event Storming，也可以叫事件風暴，它是一種workshop，主要的目的在幫助團隊理解和建構業務過程，以event為核心的一種視覺化的技術。

這個workshop會有哪些人參加？

• 開發人員
• stakeholder
• domain expert
• user representatives

參加的不止開發人員！？為什麼呢？

要記住一個重點，產品不是給開發人員使用的，而是給user使用，如果今天開發團隊只在乎自己的喜好去開發，就算開發的產品在好，其他人不買單也是失敗。
因此呢，先從開發者的角度抽離出來，要以其他角色的角度思考，怎麼樣產品能讓所有人滿意。
在workshop的過程中，stakeholder(跟產品有利益的關係人)、domain expert以及user的代表都會參與討論，最終彼此都有共識，對結果很滿意。
在這個workshop當中，不會談到相關技術，只會描述與商業行為有關的句子。

透過Event Storm的workshop，團隊在跟user、domain expert討論的時後，不會再是非開發人員與開發人員雞同鴨講，你說你的我說我的，越到後期分歧越大，最後的結果不僅讓開發效率大減，還有可能開發方向錯誤導致得重新再來。

Event Storming vs Event Driven

• Event Driven Architecture: 能夠根據event的觸發做出相關操作的系統架構，確
  保event的可靠性和即時性
• Event Storming: 是與團隊的其他非開發成員合作，了解業務流程中的重要event以及它的關係所在，並用event為中心來延伸商業邏輯，對於後續的系統設計和實作有非常大的幫助，確保團隊成員們之間的溝通

總結

今天我們說明Event Storming的核心思想是什麼，以及它的目的以及給團隊帶來什麼好處，同時也比較Event Driven Architecture與Event Storming的不同之處。
Event Storming流程怎麼走的我就不多加描述了，不然又要多開好幾篇來說明。
明天開講pub-sub!

好了～～今天就到這邊!!

Reference

來場輕便可攜的 Event Storming 吧！