[讀書會] 領域驅動開發 第14章 - 保持模型完整性

這個部分是與朋友私下讀書會的筆記，前面的章節講的是一些軟體設計上的原則，是單人設計時就可以使用的原則，而這一章的內容較偏重於大型系統多個團隊的協作。當軟體系統越來越大，開發上可能依賴於其他的系統，或者需要多個團隊進行開發，就需要更高層級的戰略設計，在DDD中會以Context作為單位來劃分，但這個劃分並不一定有制式的方法，除了原本領域的切分外，也會考慮到團隊工作劃分，我的感覺是同一個專案在不同時空背景下，切的結果不一定相同。這個章節對於同一個Context內部開發與多個Context之間的協作進行介紹，作為規劃時的參考。

---

Bounded Context

Bounded Context要注重的是當下的情況，而不是系統最理想的情況

舉例:

• 背景：運輸公司內部專案
• Context:
  • 遺留代碼的預訂系統 - 負責新舊系統邊界的橋接
  • 新的預訂系統 - 只注意context內容，新舊轉換在context之外，開發時不考慮
  • 航次安排系統 - 與新的預定系統有某種程度上的概念重合，但屬於不同的context，重複的部分應該在修改之後才共用

Context中的不一致

1. 重複概念
2. 假同源

整合Context

1. Continuous Intergation 範圍是在同一個Context中
   1. 使用可重現的合併/建構技術
   2. 自動測試套件
   3. 元件生命週期管理
   4. 使用Ubiquitious Language
2. Context Map 描述模型間的聯絡點，明確所有通訊需要的轉換，並突出共用的內容 先描述現況，以後再改變 舉例:
   • 航次安排與路徑演算
     1. Route Specification -> Place List
     2. Node -> Itinerary
   • 不需要將兩個context中全部的概念進行映射
   • 聯絡點的測試很重要

整理Context Map

1. 須整合時的策略
   1. Sharded Kernel
      • 避免Context之間各行其道難以整合
      • 避免花費大量精力在轉換層
      • 抽出共用的核心邏輯
      • 需要整合但是不需要像Continuous Intergation頻繁
   2. Customer/Supplier
      • 下游元件依賴上游元件，單向依賴
      • 必須是客戶與供應商關係(外圍元件向內部反饋後，內部會做相應調整)
      • 測試
   3. Conformist
      • 下游只能跟從上游
      • 上游的品質不會太差
      • 不能夠達到最佳化，但可以減少整合成本
   4. Anticorruption Layer
      • 避免須整合系統滲透到新系統中(防護 defensive)
      • 整合現有系統是一種價值重用
      • 不同模型與協議之間轉換價值的機制
      • Facde/Adapter、translator與通訊傳輸機制
      • 大範圍轉換使系統接近所依賴的外部系統時可考慮使用Conformist
2. 不需整合時的策略
   1. Seperate Way
      • 整合的代價高昂，效益卻不大
      • 不需互相呼叫、操作期間不共享資料 => use case相關不代表必須整合
      • 隔離開發的模型可能很難合併
3. 提高整合度的模式
   1. Open Host Service
      • 子系統需要以多個系統整合 => 客製化整合會拖慢進度，也更難維護
      • 設計乾淨的協定，並且易於擴充
      • 只有在子系統資源可以被描述為一組內聚的service並且進行很多整合時才適合
   2. Publishd Language
      • 兩個Context間的直接轉換(直接相依於某一方)可能會造成僵化的設計
      • Publish Language不屬於兩個模型中的任何一個，但是應用原則一致
      • 將A系統中的資料以JSON格式傳到B系統

模型整合

1. 多個context可能存在衝突的部分=>承認互相衝突的領域模型
2. Context Map反映當前的狀況，並作出調整
3. 開發時需注意到已經超過應用邊界
4. 外部系統自身不一定構成完整的context
5. 系統內部的Context劃分 => 隨著規模變大從一到多