領域驅動設計學習筆記（12）：Event Storming與User Story

Dec. 27 20:05~21:45

▲ezKanban團隊的開發流程

問題

有朋友問Teddy：「Event Storming做完之後，如何轉成user story與團隊溝通？」

在ezKanban開發過程中，團隊的開發流程從2020年暑假開始從Scrum轉成Kanban。團隊不再額外寫In order too [獲得什麼好處]….As a user, I want to [做什麼事] 這種格式的user story，而是直接將Event Storming的Command變成Use Case放到product backlog裡面。

傳統OOAD的Use Case其粒度一般來講比user story要大，一個Use Case可能有多個執行路徑或多個劇情，每一個執行路徑可視為一個user story。所以直接以Use Case來取代user story，有可能會違反敏捷與精實開發的小批量生產原則—開發的功能儘量切小，可獲得較短的交期（lead time）。不但bug會比較少，品質較好，也可以快速收集使用者回饋。

ezKanban團隊在Event Storming的過過程中不是從CRUD的角度來尋找領域事件，而是找出任務導向（task-oriented）的領域事件，並且採用TDD/BDD/SBE的方式實作Use Case。因此從實作面的角度，也是以step by step、piece by piece、scenario by scenario的方式完成使用者需求，並不會因為沒有將Use Case改寫成user story就造成溝通或是開發上的問題。

***

範例說明：Move Lane使用案例

圖1：Move Lane Command

視覺化是實施看板方法的第一條原則，因此ezKanban軟體自然要提供設計工作流程的功能，讓使用者可以新增Stage（垂直的工作階段）與SwimLane（水平的工作階段）。除此之外，使用者在視覺化工作流程的時候經常需要調整工作流程的順序與層級，因此Move Lane（移動工作階段）使用案例也很重要，如圖1所示。

使用者可以直接用滑鼠將最上層的工作階段拖拉到想要的順序，如圖2所示，使用者正在把Reviewed移到Ready to Deploy之後。

圖2：實作完成的Move Lane畫面

***

實作Move Lane使用案例

因為採用TDD方式開發，因此先撰寫第一個Use Case的測試案例—移動最上層的Stage。請參考圖3，這個測試案例代表最常見使用情況的happy path。

圖3：Move Lane的第一個測試案例

一開始這個測試案例根本無法編譯，因為都還沒寫production code。接著就按照TDD的流程，以最簡單的方式撰寫讓測試案例可以通過的production code，再透過重構來改善設計。

因為移動工作階段這個功能比較複雜，光靠Use Case的驗收測試無法涵蓋所有可能的移動情況，因此以specification by example的精神，以單元測試來代表移動工作階段的各種可能狀況，單元測試案例執行結果請參考圖4。

圖4：Workflow身上的moveLane方法的單元測試

針對move lane的各種狀況，ezKanban團隊目前一共寫了9個單元測試，從單元測試的名稱就可以很清楚看到所想要涵蓋的情況，例如以下兩個單元測試代表移動工作階段的邊界條件測案例。

• should have correct order when move substage0 from order0 to order0 in the same parent
• should have correct order when move substage4 from order4 to order4 in the same parent

單元測通過之後，回頭跑Use Case測試案例，順利通過就完成Move Lane使用案例的第一個happy path。

接著撰寫第二個Move Lane使用案例的驗收測試—should succeed when move second root stage containing sublane to first root stage，這個案例比較複雜，代表兩個平行的stage A 和stage B，其中stage B底下還有其他的stages，然後把stage B移到stage A底下。

這兩個驗收測試都通過之後，就可以撰寫rest controller，完成後再寫前端的react程式，把前後端接起來這個Move Lane功能就完成了……第一版。

上述提到兩個驗收測試都是移動Stage，還需要增加移動SwimLane的驗收測試，測試通過後整個Move Lane使用案例才可以算是完成。

目前ezKanban團隊的TDD僅限於use cases與entities這兩層的物件，這兩層以外的開發並沒有採用TDD，而是採用傳統code first方式。

***

通用語言表現在程式碼

領域驅動開發有一個重要的觀念—Ubiquitous Language in Code，能夠做到這個層次，開發團隊本身，以及開發團隊與stakeholders（尤其是domain experts）的溝通也就沒什麼問題。

Teddy整合了DDD、Event Storming、Clean Architecture與TDD/BDD/SBE，首先透過event storming建立ubiquitous language 與domain model，接著透過clean architecture與TDD將ubiquitous language落實在程式碼之中。以上這些都做到之後，如果覺得還是需要撰寫傳統的user story，那也沒關係，就去寫吧。

***

友藏內心獨白：到了離，就不用守了。