領域驅動設計學習筆記（14）：依據領域事件流動方向調整Bounded Context的依賴關係

Jan. 05 13:45~17:38

▲事件流動方向也代表bounded context之間依賴的方向

今天談一個開發ezKanban時，只專注在core domain而沒有同時關照到context map所踩到的坑 。

背景

ezKanban目前有四個Bounded Contexts：

• Account：負責註冊。
• Team：負責管理團隊、專案、以及看板的使用權限。
• Board：負責表達看板中的工作流（Workflow）以及卡片（Card），此為ezKanban的核心領域（Core Domain）。
• Report：負責產生累積流量圖（Cumulative Flow Diagram；CFD）、交期分布圖（Lead Time Distribution Chart）、控制圖（Control Chart）等圖表。

這幾天ezKanban團隊正在開發Add Member To Team與Add Member To Board的使用案例，原本的設計Add Member To Team屬於Team Bounded Context，而Add Member To Board則是屬於Board Bounded Context的功能，如圖1所示。

▲圖1：Team與Board Bounded Contexts的domain model（部分）

***

問題

Add Member To Team做完之後緊接著要做Add Member To Board，此時發現：

• Board member必須是team member，因此Add Member To Team需要接受前端傳來的List<Team Member>當作參數。
• Team bounded context的Team member被移除之後，很顯然地Board bounded context的board member也要被移除。
• 因為Team與Board屬於不同Bounded Context的不同Aggregate，因此彼此之間的狀態同步要透過領域事件達到最終狀態一致性。

到目前為止看起來都沒什麼問題，問題出在：

• Team會去聽Create Board所產生的BoardCreated領域事件，以便在它身上加上一個Board物件，作為在團隊儀表板功能顯示給使用者看。
• Board也要聽TeamMemberRemoved領域事件，以便將自己身上的Board member移除。

如此一來，Team和Board這兩個bounded context便產生循環參考。

***

真理之源 (Source of Truth)

Team和Board因為領域事件產生耦合，在分散式系統中，可以在它們兩個之間架上Message Queue，以隔開兩者的直接相互參考。這樣做程式可以動沒問題，但這個現象讓Teddy思考：「兩個Bounded Context互相參考，是否意味著Board bounded context裡面的board物件，應該移到Team bounded context裡面？」

ezKanban的開發順序，先從Board bounded context這個core domain開始，此時主要關注點是工作流程是否可以表達問題領域的各種狀況，以及卡片的設計與流動，等於乎應看板的三個核心原則：

• 視覺化
• 限定WIP
• 管理工作流

所以一開始代表「看板」概念的領域物件—Board被設計放在Board bounded context，等到board bounded context基本功能完成之後，團隊才開始實做Team bounded context，一直到實作至Add Member To Board才發現上述相互參考的問題。

Board這個概念，原本在Team bounded context與Board bounded context都存在，這沒問題。ezKanban的問題在於：「新增Board的時候，這個代表Board資料的Source of Truth應該要存在Team bounded context，而不是存在Board bounded context。」為什麼？現在想想也很簡單，因為從使用者操作ezKanban的時間順序來看，使用者是先在Team bounded context新增一個Board，接著才進入這個Board去設計工作流程與卡片，如圖2。

▲圖2：Team bounded context設計好之後，很明顯可以看出，Board的原始資料應該存放在Team裡面

***

友藏內心獨白：訊息流動的方向也要注意。