相較於第一天的演說形式，第二天主題是各式工作坊。身為一個工程師當然是直接選擇技術軌，由 3D 四少 REFK — River, Eason, Fong, Kim 帶來的『DDD 深度歷險：從戰略到戰術』。四位大大加上助教群百年功力（？）加持下，工作坊可謂收穫滿滿。
工作坊分為三個部分： 事件風暴 Event Storming、戰術建模 Tactic Modeling、以及 Example Mapping，最後一部分由於有事提早離開沒有參與到，這裡就來分享一下第一次玩事件風暴以及戰術建模的一些想法。
事件風暴 Event Storming
事件風暴這類大型協作討論，首選還是使用超大的白板，不過現場工作坊分成八組，沒有地方放八個超大白板， 因此使用的是電子白板軟體 miro。先給大家看我們的成果，主題是假想的機票搜尋訂購網站的系統流程： https://miro.com/app/board/o9J_leUokrk=/
首先，無論事件風暴、User Story Mapping 或是 Wireframe ，背後都有個重點：對齊大家的認知，避免產生各種錯覺。同時透過群體討論破除各自的知識詛咒、認知固化所產生之盲點，並建立群體的共識。而事件風暴則是透過團隊與領域專家共同討論，讓團隊能夠把領域知識轉化為系統架構與流程的一個過程。
另一方面，事件風暴也是會議的一種，而會議應該要有目標以及產出。事件風暴的大目標是讓大家可以了解問題領域內發生了什麼事情，產出是貼在白板上的一堆便利貼所形成的整體流程。
事件風暴粗略可以分成幾大塊：
步驟一：列出發生之事件
步驟二：疏理成順暢的故事流程
步驟三：找出使用者與命令
看起來簡單的幾個步驟，實際上需要參與成員大量的討論來回。比如說我們在一開始由『領域專家』（各組自行指派的角色）拿著需求進來討論時，就花了至少十分鐘聆聽使用情境，再花十分鐘去確認大致的流程細節。
後續的討論比較多圍繞在『阿這個算是事件／使用者／命令嗎？』這類的事件風暴初學者問題。雖然說時間只有上午三個小時，但透過組內成員的討論，偶爾把講師群們拉進來問問題，對於整個事件風暴也算是有了個第一次的試用體驗。
這樣跑下來有幾個想法：
- 我們小組的領域專家是假扮的，自然很容易被問倒，這時他會大方坦承自己不知道。試想如果實際情況下我們找來一個不懂裝懂的領域專家呢？領域專家可說是事件風暴的核心，但因其有著其他人無法理解的領域專業，不誠信的時候大家也無法判斷，因此我們必須找 誠信、可信賴 的領域專家，才有辦法獲取『真實及全部之事實，且無虛言 (the truth, the whole truth, and nothing but the truth)』。
- 電子白板的協作能力仍然不及實體白板：不可否認電子白板很方便，優勢是無限的空間加上能夠遠端作業，但大家光是搞清楚怎麼使用就要花上一些時間，對於平常就在碰電腦的開發團隊來說還好，但如果領域專家數位化程度不高就會需要有人幫忙。另外使用電腦需要額外的專注力，無論是電子白板的操作、不小心的分工／分心，都會造成討論效率降低，也有可能導致盯著螢幕好像很專心但實際上沒有任何產出的情形。
- 協作能力是基本要求：這有點廢話，因為只要兩個人以上的場合想要順暢溝通，就需要協作能力。但事件風暴中的領域專家通常是團隊之外不熟悉的人，且參與的時間通常就那麼一陣子，如果團隊具備良好的協作能力就有辦法更快更精準地獲取想要的領域知識。
- 廟公（Facilitator）的重要性：事件風暴不是多數人會的技能，也因此真實情況下使用時很大機率有參與者不清楚。如果連執行的團隊本身也不熟悉，就會需要有多一點比例的『學習』，等到多數人（或至少一些關鍵的參與者）熟悉之後，再以事件風暴本身想解決的『釐清領域知識』目標來執行。但無論如何參與者不會每次都一樣，也很低機率是所有人都熟悉遊戲規則，因此有一個熟悉規則的廟公幫忙引導整個事件進行，協助不熟悉的人進入狀況，對於整個事件進行會有很大的幫助。就如同工作坊時大家都不懂，有講師群們在旁邊引導，就會比組員們自行討論來得有效率許多。
- 技術只是細節：問題 → 解法 → 實作，這三件事之間的依賴性是這樣子的。工程師本位的思考很容易事件討論討論就開始想說那系統實作時會遇到的困難。雖然說技術上如果做不到討論再多似乎也不一定有用，但在事件風暴層級的討論是屬於『問題層級』的流程，也就是一個人遇到問題的處理方式。而系統實作面是屬於『解決方案』的部分，在事件風暴中我們想達成的是『問對問題』，先把問題問對問清楚，後續要採用什麼技術可以再來思考。
講到電子白板幾乎都是用 Miro，雖然真的很好用但這邊想推個個人偏好 whimsical ～ 功能少一些，但樣式的設定就能夠單純點，整體的風格也比較統一。如果僅是要用在 event storming 便利貼的紀錄其實滿夠用的（且便利貼內還可以有討論串）。缺點是沒辦法像 miro 一樣一個畫布可以拿來貼便利貼、化流程、甚至手繪線條。對於 event storming 後續要轉換為流程圖、設計圖之類的，就需要多開一個畫布連結。戰術建模
下午的戰術建模則是延續上午的事件風暴產生之流程，開始去產生 Bounded Context、Aggregates、Value Object、Entities 這些模型。這邊看起來又更接近實作面，但實際上是在『解決方案』的部分，我們試著建立出一個符合解決方案程序的系統架構。
- 我們如何看待一個問題，會大幅影響解決方案的形塑，因此也會造成系統實作上的不同。以工作坊主題『機票搜詢訂購系統』來說，有些組別會把重點放在購票經驗、有些則是找出最合理的價格，不同的看法產生的差異，透過戰術建模，就會反應在各種模型的劃分上。當然，不同角度的觀看者，也有可能一個人覺得是 entity 的東西，另外一個人覺得是 value object。
- 一樣是個協作的過程，不過這階段領域專家的參與度較低，通常是顧問角色，問一下情境、規格以及最後的使用驗證這樣。這裡因為大家都不熟悉各種模型的定義與使用方法，所以工作坊多數時間都是在釐清定義並且使用，或者是用錯誤的方式使用後被好心的講師群們釐清定義，各種模型是什麼、邊界該怎麼切、模型與模型之間有什麼樣的關聯等。實際應用上如果有一定的熟悉度後應該是會有比較多的時間討論這些模型是否能解決想解決的問題、關聯性是否合理等比較偏流程面的問題，或是進一步探討實作上的細節。
- 戰術建模之後工程師應該會比較有感，因為有了明確的範圍、集合，未來就可以變成物件或是資料庫的 table。所以工程師應該會開始冒出更多的疑問：這個系統關係跟現在的有衝突該怎麼辦？這邊看起來很複雜要怎麼做啊？這時就要思考，這個疑問是實作細節可以實作時再來煩惱，還是他其實是個影響系統流程的重要問題？如果是重要的問題可能會導致我們因此需要回頭檢視事件風暴的流程，而如果只是技術細節則可以到實作時再來決定。
- 由於我們理解世界的方式是線性的，事件風暴建立出的流程就很容易理解，轉換為模型時如果流程消失的話就容易讓人迷失在模型中。這時我們可以透過 Context Mapping ，用同樣的流程把這些模型串連起來。
- 這階段也很需要統一語言，物件才好命名，但領域專家也可能不知道該如何命名，這時候就需要團隊展現一些創意或是參考同行了。
後記
世界上兩件事最難：一是把別人的錢裝進自己的口袋，二是把自己的思想裝進別人的腦袋。
其實 DDD 在處理的跟這兩件事情也有關係：透過事件風暴、統一語言與戰術建模等，互相理解互相洗腦。然後希望產品能夠提供足夠的價值，讓別人主動把錢裝進自己的口袋。
參與這兩天收穫很多，不過講歸講還是要實際應用才有意義，短期的話應該會先在內部試跑個事件風暴，以及認真地建立一些詞彙庫。
想跟我一起玩的，這裡有個好職缺 https://www.yourator.co/companies/Yourator/jobs/13778
