上下文對應

🎯 什麼情境該想到我

當你「系統已經被切成好幾個模型/服務，但沒人講得清它們之間怎麼整合、哪個依賴哪個」的時候。你需要一張全局圖，看清各限界上下文與它們之間的整合方式與團隊關係，避免不知不覺的耦合。

⚙️ 怎麼用（步驟 / 公式）

意圖：畫出系統中所有現存的限界上下文，以及它們彼此之間的整合關係與團隊關係，讓全局可見，避免無意識、隱性的耦合傷害。

做法要點：

盤點目前實際存在（而非理想中）的限界上下文，一個一個標出來。
標出每對上下文之間的關係，用既有的關係模式命名（共享核心、客戶-供應商、追隨者、防腐層、開放主機服務、發布語言、各行其道、合作關係等）。
標明上下游方向與翻譯點：資料/概念在哪裡跨界、由誰翻譯、誰受誰的變動影響。
把地圖當溝通與決策工具持續更新，作為整合與團隊協調的依據。

★★ 它的真正用途：把「組織現實」畫出來，而不是畫架構圖

★★ Evans 的關鍵洞見：★ 上下文之間的關係，本質上是「團隊之間的權力關係」。
  ★ 「我們可以要求對方改嗎？」
  ★ 「對方改了會通知我們嗎？」
  ★ 「誰承擔翻譯的成本？」
→ ★★ 九種關係模式（見下）不是技術選項，★ 而是「你在這個關係裡有多少話語權」的分類

★★ 所以上下文對應圖上最重要的不是方框，是箭頭上的標籤——
★ 它記錄的是「這個整合為什麼是這樣」，而那通常是組織原因，不是技術原因。

★★ 九種關係，按「你的話語權」排序

關係	你的話語權	一句話
合作關係	★★ 對等	兩隊命運綁在一起，一起成功或一起失敗
共享核心	★★ 對等但高耦合	共用一部分模型與程式碼
客戶-供應商	★ 上游有義務配合下游	有排程協商、有回歸測試
追隨者	★★ 你沒有話語權	上游不配合，你只能照抄它的模型
防腐層	★ 你沒有話語權，★★ 但你付錢買自主	自己寫一層翻譯
開放主機服務	★ 你是上游，要服務多個下游	定義一個穩定的公開協定
發布語言	★ 同上，強調「格式」	一個共享的、有版本的交換格式
各行其道	★★ 不整合	成本大於收益，各自做
大泥球	★★ 沒有邊界	標示出來，別讓它擴散

★★ 最重要的三個判斷：

① ★★ 上游會為你改嗎？
   會 → [[客戶-供應商]]；不會 → ★ [[追隨者]] 或 [[防腐層]]
② ★★ 你能接受上游的模型滲進來嗎？
   能（模型相近、變動少）→ [[追隨者]]（★ 便宜）
   不能 → ★★ [[防腐層]]（★ 貴，但保護你的模型）
③ ★★ 真的需要整合嗎？
   → ★ [[各行其道]] 常常是被忽略的正確答案

★★ 怎麼「畫」一張有用的上下文對應圖

★ 五個必須標在圖上的東西（少了任一個，圖就只是裝飾）：
① ★★ 每個上下文的「擁有團隊」 —— ★ 沒有擁有者的上下文是問題本身
② ★★ 箭頭的方向 = 依賴方向（★ 不是資料流方向，兩者常相反）
③ ★★ 關係型態（上表的九種之一）
④ ★ 整合機制（同步 REST／gRPC／事件／批次檔案／共享 DB）
⑤ ★★ 「翻譯發生在哪一側」 —— ★ 這決定了誰付成本

★★ ② 最常被畫錯：

★ 訂單服務發事件 → 出貨服務訂閱
  ★ 資料流：訂單 → 出貨
  ★★ 依賴方向：出貨 → 訂單（★ 出貨依賴訂單的事件 schema）
→ ★ 畫成「訂單 → 出貨」會讓人以為「改出貨要通知訂單」，而實際上相反

★★ 它最大的實務價值：讓「不要整合」變成一個可以說出口的選項

★ 沒有上下文對應圖時的對話：
  「這兩個系統要不要整合？」→ ★ 「當然要，不然資料不一致」
★★ 有圖之後的對話：
  「整合成本是：一個防腐層 + 兩邊的 schema 協商 + 最終一致性的 UI 處理」
  「收益是：★ 每月省五個人工作業小時」
  → ★★ 「那先不要整合」變成一個可以量化、可以被接受的結論（[[各行其道]]）

★ 這是 DDD 戰略設計最實際的產出——★★ 它讓整合決策從「應該」變成「值得嗎」。

★★ 維護它：它一定會過時，除非有一個具體機制

★ 三個實際可行的做法：
① ★★ 把圖放在程式碼庫裡（Mermaid／PlantUML 的文字檔）
   → ★ 進版控、可 diff、review 時看得到變化
② ★★ 讓「新增一個跨上下文整合」的 PR 必須更新圖
   → ★ 一條 checklist 或 CI 檢查
③ ★ 從程式碼自動推導一部分
   ★ go list -deps 或 depguard 的規則已經是一份「機器可讀的上下文對應」
   → ★★ 圖是給人看的；depguard 是給編譯器看的（見 [[限界上下文]]）

★★ ③ 是最有價值的一條：★ 讓邊界同時存在於「圖」與「CI」裡，
圖會過時，但 CI 不會。

🧪 我實際套用的紀錄

（待填）

⚠️ 注意 / 什麼時候不適用

上下文對應描述的是「現狀」，先照實畫，別畫成理想架構圖，否則會誤導決策。
它是溝通與策略工具，不是精細的技術架構圖；細節過多反而失焦。
地圖會過期，關係一變就要更新，否則會誤導後續整合判斷。
★★ 箭頭方向是依賴方向，不是資料流方向，兩者常相反。 訂單發事件、出貨訂閱 → 依賴方向是「出貨 → 訂單」。畫錯會讓人以為改出貨要通知訂單。
★★ 九種關係是「你在這個關係裡有多少話語權」的分類，不是技術選項。
★★ 圖上必須標「擁有團隊」與「翻譯發生在哪一側」。後者決定了誰付成本；沒有擁有者的上下文是問題本身。
★★ 它最大的價值是讓「不要整合」變成可以說出口的選項（各行其道），把決策從「應該」變成「值得嗎」。
★★ 圖一定會過時，除非有機制：放程式碼庫（Mermaid 文字檔）、PR checklist、以及最重要的——用 depguard 讓邊界同時存在於 CI 裡。
★ 三個核心判斷：上游會為你改嗎、你能接受它的模型滲進來嗎、真的需要整合嗎。
★ 只有方框沒有標籤的圖是裝飾品。 關係型態、整合機制、翻譯位置才是內容。
不要把上下文對應圖畫成微服務部署圖。 它畫的是模型邊界與團隊關係。

🔗 相關工具

限界上下文 Bounded Context（地圖上的節點）
防腐層 Anticorruption Layer（地圖上常見的一種整合關係）
客戶-供應商 Customer-Supplier（上下游關係的典型模式）
領域驅動設計
限界上下文 —— 圖上的方框
合作關係、共享核心、客戶-供應商、追隨者、防腐層、開放主機服務、發布語言、各行其道、大泥球 —— ★ 九種關係
康威定律作為設計工具 —— 團隊邊界與模組邊界
工具-服務邊界與演進式拆分 —— 何時升級成部署邊界

Quartz 5

Explorer