Quartz 5

合作關係

Properties1
tagsddd, domain-driven-design, context-mapping

10 min read

🎯 什麼情境該想到我

當你「兩個上下文的團隊命運綁在一起——一邊失敗另一邊也跟著失敗，功能必須協同規劃、一起交付」的時候。你需要一種雙向承諾的緊密協作關係。

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

意圖：兩個上下文的團隊建立對等的合作關係，因為彼此成敗與共。雙方承諾協同進行功能規劃、整合節奏與交付，共同對整合成功負責。

做法要點：

  1. 確認兩上下文確實高度相互依賴、成敗綁在一起，才適用此模式。
  2. 建立共同的規劃機制：一起排功能、對齊介面與交付時程。
  3. 協調整合節奏，讓雙方的變更同步演進、彼此不拖後腿。
  4. 建立持續溝通與共同的整合測試，維持這份雙向承諾。

★★ 它的定義比聽起來嚴格：「一起成功或一起失敗」

★ 合作關係（Partnership）的前提：
  ★★ 兩個上下文的「交付成敗綁在一起」——★ 一邊做不出來，另一邊的功能就沒有意義
  → ★ 所以它們必須：★ 協調發布時程、★ 共同規劃介面、★★ 一起承擔失敗

★★ 判準：如果 A 延遲兩週，B 這一季的目標會不會失敗？
會 → ★ 這確實是合作關係。
不會 → ★★ 它其實是 客戶-供應商（有先後、有依賴，但不是共同存亡）。

★★ 它是九種關係裡「成本最高」的一種

★ 合作關係的實際成本：
① ★★ 雙向的溝通成本 —— ★ 任何介面變更都要兩邊同意
② ★★ 發布必須協調 —— ★ 無法獨立部署（★ 或者需要 feature flag 配合）
③ ★★ 測試必須整合 —— ★ 需要一組跨上下文的驗收測試，而且它們很慢、很脆
④ ★ 事故責任模糊 —— ★★ 「這是誰的問題」在合作關係裡常常沒有答案

★★ 所以它應該是「刻意選擇的少數」，不是「自然演變的多數」。
★ 若你的上下文對應圖上有五條合作關係 →
那不是合作，是 大泥球 還沒被畫出來。

★★ 什麼時候它是對的（三個真實場景）

① ★★ 一個新產品的初期
   ★ 兩個團隊同時開發前端與後端、或核心與計費
   → ★ 邊界還在探索，強行定義契約只會定錯
   → ★★ 但要有退出條件：★「三個月後邊界穩定了就降級成客戶-供應商」

② ★ 一個橫跨兩個上下文的大型功能
   ★ 「導入訂閱制」需要計費與訂單同時改
   → ★★ 這是「暫時的合作關係」，功能上線後回到原本的關係

③ ★ 兩個上下文其實該合併，但暫時不能
   → ★★ 合作關係是一個誠實的中間狀態（★ 而不是一個目標狀態）

★★ 共同點：★ 它都應該是暫時的，而且要有明確的退出條件。

★★ Go／工程上的具體配套（沒有這些，「合作」只是口號）

① ★★ 共用的契約測試（★ 最重要的一項）
   ★ 兩邊共用一份 .proto 或 OpenAPI，★★ 而且 CI 會驗證雙方都符合
   → ★ 用 Pact 之類的消費者驅動契約，或最簡單的：
     ★★ 一組「golden file」測試，任一方改變回應形狀就紅燈

② ★★ 協調的發布機制
   ★ 需要同時上線 → ★ feature flag（★ 兩邊都先部署，再一起開）
   → ★★ 「同時部署」在實務上做不到；★ 一定要有「舊版能容忍新版」的過渡

③ ★ 共用的 trace
   → ★★ 跨上下文的因果鏈必須看得到（見 [[關聯識別碼]]）

④ ★★ 一個明確的「介面變更流程」
   ★ 誰可以改？改了要通知誰？多久前通知？
   → ★ 沒有這個，「協調」會退化成「事後才知道」

★★ ② 的「同時部署做不到」是最實際的一條：
★ 就算兩個團隊約好同一天上線，滾動部署期間一定有新舊並存的時刻。
→ ★★ 所以合作關係仍然需要向後相容的介面演進（見 工具-資料編碼與演進）。

★★ 它最常見的失敗：從來沒有真正協調

★ 真實的樣貌：
  ★ 兩個團隊名義上是「合作關係」
  → ★★ 但沒有共用的契約測試、沒有協調發布的機制、沒有介面變更流程
  → ★ 於是：★★ 一邊改了介面、另一邊在整合測試才發現、雙方互指對方
  → ★ 最後演變成「其中一方變成事實上的 [[追隨者]]」（★ 通常是話語權小的那一方）

★★ 判準：你們上週有為了介面變更開過會嗎？
沒有 → ★ 那不是合作關係，只是兩個耦合的系統。

★ 兄弟辨析

差別
共享核心★ 更進一步：共用程式碼／模型，而非只是協調
客戶-供應商★ 有明確的上下游；上游有配合義務但不共同存亡
追隨者★ 一方完全沒有話語權
各行其道★ 不整合

🧪 我實際套用的紀錄

  • （待填）

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

  • 需要兩隊有良好關係與高頻溝通；團隊間信任不足或無法密切協調時撐不起來。

  • 協調成本高，只在「真的成敗與共」時才值得；關係沒那麼緊密時用客戶-供應商即可。

  • 與共享核心常相伴，但合作關係強調的是「共同規劃與交付的承諾」，不必然共用同一份程式碼。

  • ★★ 判準：如果 A 延遲兩週，B 這一季的目標會不會失敗？ 不會 → 它其實是 客戶-供應商。

  • ★★ 它是九種關係裡成本最高的一種，應該是刻意選擇的少數。圖上有五條合作關係 → 那是還沒被畫出來的 大泥球。

  • ★★ 它應該是暫時的，而且要有明確的退出條件（「三個月後邊界穩定了就降級」）。

  • ★★ 「同時部署」在實務上做不到 —— 滾動部署期間一定有新舊並存。所以合作關係仍需要向後相容的介面演進。

  • ★★ 沒有共用契約測試、協調發布機制、介面變更流程 → 那不是合作關係，只是兩個耦合的系統。

  • ★ 判準：你們上週有為了介面變更開過會嗎？ 沒有 → 名義上的合作。

  • ★ 它最常見的下場是「其中一方變成事實上的 追隨者」，通常是話語權小的那一方。

  • 事故責任在合作關係裡常常沒有答案，這本身就是一個要處理的問題。

🔗 相關工具

Graph View

Backlinks