領域驅動設計學習筆記（11）：Bounded Context（上）

Dec. 18 13:01~17:35

▲ezKanban的儀表板畫面

只有一個Context的問題

Bounded Context在領域驅動設計（Domain-Driven Design；DDD）中是一個很重要個概念，今天先從實作面談一下有無Bounded Context的差別。以往傳統的物件導向設計，整個問題領域就是一個巨大的Context，因此在solution domain自然產生一個很大的物件類別圖， 如圖1所示。

▲圖1：Class diagram，取自JCIS

為了簡化程式設計，這個object graph之內的物件關係往往被設計成雙向連結。例如，圖2是一個用傳統OOAD所設計出的看板系統，其簡化後的類別圖：

• Team：團隊，每一位使用者至少屬於一個團隊。
• Project：專案，一個團隊有零到多個專案，可以從團隊得到屬於該團隊的專案，也可以從專案得到所屬的團隊，團隊與專案兩者之間是雙向參考關係。
• Board：板，代表一個看板。一個專案可以有零到多個看板。專案與板之間也是雙向參考關係。
• Workflow：工作流，一個板可以有零到多個工作流，兩者之間也是雙向參考關係。
• Lane：道，代表工作階段。Lane有兩個子類別，分別是代表垂直的Stage，以及代表水平的Swimlane。Lane與Workflow之間也是雙向參考關係。

▲圖2：Class diagram，取自JCIS

程式開發人員可以用team.getProject().getBoard().getWorkflow().getStage() 得到某個Stage。相反地，也可以從stage.getWorkflow().getBoard().getProject().getTeam()得到該Stage所屬的團隊。這麼做的好處是，物件之間靠著參考 (reference) 整個串在一起，操作物件感覺很方便。有優點一定也有缺點，主要的缺點有三項：

• 相依性太重：任一物件修改都可能會影響其他物件，容易產生漣波效應。
• 物件永久性與平行處裡的能力受限：為了達到整個系統交易（transaction）的一致性，物件與關連式資料庫經常透過多的表格與外鍵關係來實現。當使用者更新系統物件時，可能需要鎖定多個表格，因而降低系統的平行處理能力。
• 物件屬性與責任膨脹：整個問題領域只有一個Context，如果問題領域夠大，相同的類別在不同的功能中可能有不同的屬性與責任。例如，從Team與Project的角度，Board只是一種被分類的「東西」。除了board id與board name以外，它們並不在乎Board裡面的實質內容。但是，從Board、Workflow、Lane的角度，Board的內容是整個功能的核心。因為整個系統只有一個Context，因此只有一個Board類別，所以Board類別身上就會包含所有「客戶端」所需要的資料與方法。

***

Bounded Context

▲圖3：兩個bounded contexts

如圖3所示，有了bounded context概念，如果把原本的問題分成兩個bounded contexts：

• Project Management
• Board Management

Board同時出現在兩個bounded contexts之中，但是有著不同的意義與屬性。Project Management的Board只需要有board id、board name、project id、team id即可。而Board Management的Board才需要workflows等資料。

如此一來，當Project Management移動Board，就與Board Management的Board沒有關係，解決了上述只有一個Context所造成的三個問題：

• 相依性太重
• 物件永久性與平行處裡的能力受限
• 物件屬性與責任膨脹

區分Bounded Context還有其他好處，像是在多個Bounded Context中找出企業最具競爭力的core domain，以便區分業務優先順序以及安排開發資源。

***

代價

區分Bounded Context所付出的代價就是當企業流程或資料跨越不同Bounded Context時，需要協調這些活動與資料。例如，當Board名稱在Project Management被修改時，需要通知Board Management更新狀態。或是當Board Management新增一個Board時候，也要通知Project Management產生一個Board。

***

友藏內心獨白：要因地制宜。