Quartz 5

各行其道

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

11 min read

🎯 什麼情境該想到我

當你「兩個上下文之間硬要整合，帶來的效益其實不值那個成本與耦合」的時候。你想明確地做出「不整合」的決定，讓兩邊各做各的，反而更清爽。

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

意圖：當兩個上下文之間沒有值得的整合效益時，明確決定「不整合」——讓它們完全各自獨立發展，藉此避免無謂的耦合與協調成本。

做法要點：

  1. 誠實評估兩上下文整合的實際效益，對照它帶來的耦合與協調成本。
  2. 若效益不足以抵過成本，明確、有意識地決定不做整合。
  3. 讓兩邊各自擁有獨立模型、獨立演進，必要時在更上層（如使用者端）各自呈現即可。
  4. 把這個「各行其道」的決定記在上下文對應上，避免日後有人又偷偷把它們接起來。

★★ 它是九種關係裡最被低估的一個：「不整合」是一個正當的選擇

★★ 各行其道（Separate Ways）= ★ 兩個上下文刻意不整合
→ ★ 它的成立條件只有一個：★★ 整合的成本大於收益
→ ★ 而★★ 這個判斷需要真的把兩邊都算出來，★ 而不是憑「應該整合」的直覺

★★ 為什麼它被低估：★ 「不整合」聽起來像放棄、像技術債，
而「整合」聽起來像進步。
★ 但整合的成本清單很長，★★ 而它常常在決策時被完全忽略。

★★ 整合的真實成本清單（★ 這是這一頁的核心）

★ 一次「把兩個系統整合起來」實際要付的：
① ★★ 介面設計與協商（★ 兩個團隊的時間）
② ★★ 翻譯層（[[防腐層]]）的開發與維護
③ ★★ 最終一致性的處理 —— ★ 包含「中間狀態怎麼呈現給使用者」（★ 產品設計成本）
④ ★★ 錯誤處理：★ 對方掛了怎麼辦、重試、冪等、DLQ
⑤ ★★ 可用性相乘：★ 兩個 99.9% 的同步依賴 = 99.8%
⑥ ★ 可觀測性：★ 跨系統的 trace 與對帳
⑦ ★★ 每次雙方改動時的回歸驗證（★ 這是持續成本）
⑧ ★ 事故時的責任與溝通成本
→ ★★ 而收益常常是：★ 「每月省五小時人工作業」

★★ 判準：把 ①–⑧ 加起來，和收益比。
★ 多數情況下，★★ 「先手動、等量大了再整合」是正確答案。

★★ 什麼時候各行其道是明確正確的

① ★★ 兩邊的使用者不同、時機不同
   ★ 財務的月結系統與客服的工單系統
   → ★ 它們「都有客戶資料」，★★ 但沒有任何一個使用者需要同時看到兩邊

② ★★ 整合的量很小
   ★ 一個月三筆資料要同步 → ★★ 人工複製比一條資料管線便宜十倍
   → ★ 而且★★ 人工有一個優點：★ 出錯時有人會發現

③ ★ 其中一邊即將被替換
   → ★★ 為一個要退役的系統建整合是純浪費

④ ★★ 整合需要跨組織協商，而收益不足以支撐
   → ★ 這是最常見的正當理由，★★ 而它通常被說成「技術上做不到」

⑤ ★ 資料的一致性要求極低
   ★ 「行銷需要大約的訂單數」→ ★★ 每晚一份報表就夠，不需要即時整合

★★ 怎麼「正確地」各行其道（★ 它不是「什麼都不做」）

① ★★ 明確記錄在 [[上下文對應]] 上，★ 並註明理由與重新評估的條件
   ★ 「2026-09 決定不整合，理由：★ 每月僅 3 筆。★★ 重評條件：> 50 筆/月」
   → ★ 沒有這一步，★★ 三年後沒人知道「為什麼這兩個系統沒有整合」
     ⇒ ★ 有人會把它當成待辦事項而不是決定

② ★★ 重複資料要有「唯一的權威來源」
   ★ 兩邊都有客戶名稱 → ★★ 明確規定哪一邊是真相
   → ★ 不規定的後果：★★ 兩邊不一致時沒有人能判斷該信哪個

③ ★ 人工流程要被寫下來，並且要有人負責
   → ★★ 「各行其道」不等於「靠某個人記得」

④ ★★ 要能偵測「不一致」
   ★ 一個每週的對帳查詢／報表
   → ★ 這是各行其道唯一的技術投資，★★ 而它成本極低、價值極高

★★ ④ 是最重要的一項：★ 各行其道的風險不是「不一致」，
而是「不一致了卻沒有人知道」。
→ ★ 一個每週跑的 SQL 對帳，★★ 比一整套整合便宜兩個數量級。

★★ 它最常見的誤用：用它掩蓋「該合併」

★ 危險的樣貌：
  ★ 兩個上下文其實在做同一件事（★ 兩個團隊各自建了一套訂單管理）
  → ★★ 標成「各行其道」⇒ ★ 聽起來像一個架構決定
  → ★★ 而實際上它是組織問題：★ 兩個團隊在重複建設
→ ★ 判準：★★ 這兩個上下文的「子領域」是同一個嗎？
  是 → ★★ 那不是各行其道，是重複建設（★ 要解決的是組織問題）
  不是 → ★ 各行其道是正當的

★ 兄弟辨析

差別
防腐層★ 整合，但付翻譯成本
追隨者★ 整合，不付翻譯成本
大泥球★★ 邊界不清的區塊；各行其道是刻意的清楚邊界
限界上下文★ 各行其道是兩個上下文之間「沒有關係」的關係

🧪 我實際套用的紀錄

  • （待填）

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

  • 若兩上下文其實真的需要協作（有實質共同流程），各行其道會造成功能斷裂與重複，不適用。

  • 這是「有意識的取捨」，不是放任脫節；要把決定講清楚並記錄，否則會被誤解成疏漏。

  • 需求會變，今天不值得整合不代表永遠；要保留日後重評的空間。

  • ★★ 「不整合」是一個正當的選擇，而它被系統性低估——因為整合聽起來像進步，而整合的成本清單在決策時常被完全忽略。

  • ★★ 整合的成本有八項（介面協商、防腐層、最終一致性的產品設計、錯誤處理、可用性相乘、可觀測性、持續的回歸驗證、事故溝通），而收益常常是「每月省五小時」。

  • ★★ 各行其道唯一的技術投資是「偵測不一致」（一個每週的對帳查詢）。風險不是不一致，而是「不一致了卻沒人知道」。

  • ★★ 必須記錄在 上下文對應 上並註明重新評估的條件，否則三年後有人會把它當待辦事項而不是決定。

  • ★★ 重複的資料要明確規定「哪一邊是真相」，否則不一致時沒人能判斷該信哪個。

  • ★★ 不要用它掩蓋「兩個團隊在重複建設」。 判準：兩者的子領域是同一個嗎？是 → 那是組織問題。

  • ★ 「整合量很小」時人工比管線便宜十倍，而且人工出錯時有人會發現。

  • 人工流程要寫下來並有人負責，不等於「靠某個人記得」。

🔗 相關工具

Graph View

Backlinks