為什麼平衡會被打破#

理想中軟體初次發布就完美對應一切現在與未來的需求；現實中軟體像生物般演化，否則就被淘汰。Chapter 9–10 已經談過模組層級的變動，本章把視角拉高到系統層級：哪些變動會把整個耦合平衡推翻？又該如何用 balanced coupling 模型回應？

模組化設計本質上是「對未來的押注」。我們不可能每次都押對。當預期之外的變動出現時，重新平衡耦合是維持設計韌性的關鍵。

Tactical Change vs Strategic Change#

軟體變動可分為兩類：

• Tactical（戰術）：「怎麼做」的變動
  • 改變實作方式但不改變問題本身
  • 例如：修 bug、最佳化效能、新增與既有業務規則一致的功能（多一個付款選項、多一個報表）
  • 良好的設計應該能容納戰術變動
• Strategic（策略）：「做什麼」的變動
  • 改變了問題本身、要解的領域、或執行的組織
  • 會挑戰既有設計的前提

策略變動的常見來源#

功能需求#

新功能 = 新知識。新知識帶來新元件、新元件帶來新互動 → 認知負擔上升 → 全域複雜度可能膨脹。

業務策略#

子領域類型本身會變：

• Generic → Core：找到比競爭對手更便宜的解法
• Supporting → Core：發現某項功能其實能成為競爭優勢
• Core → Supporting / Generic：對核心子領域的期待落空，降級它的策略地位
• Core → Generic：別人提供了同等解法（SaaS 或 OSS）

子領域類型決定了模組的易變性。一旦類型變化，設計也必須跟著調整以維持平衡。

組織變動#

組織會成長。早期 garage 時期的合作模式對中型甚至跨國公司就無效了。團隊重組、責任轉移、跨時區拆分，都會改變既有合作節奏。

環境變動#

• 技術環境：搬上雲端時的 lift-and-shift 多半失敗，因為它沿用 on-prem 的假設
• 法規：SOX、HIPAA、GDPR 都迫使既有系統重大改造（例如 GDPR 要求 data minimization、privacy by design、被遺忘權等）

三個維度的失衡與重新平衡#

任一維度劇變，都可能讓 BALANCE 由高轉低：

BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY

強度的變化#

Case Study A：隱形的整合強度#

WolfDesk 的 HelpDesks 微服務管理排班；Distribution 微服務透過事件得知排班變動，只在工作時間派發案件。

新需求出現：agent 可按 Pause Assignment 暫停 1 小時派案，每天最多 3 次。功能加入 HelpDesks，事件還是非同步發出去。

結果：agent 按了暫停，但因為事件傳遞有延遲，仍然收到新案件。業務期待是「按下立即生效」——這實際上是 transactional coupling，幾乎是最高的 functional coupling 程度。

可能的回應：

• 同步 REST API 查 HelpDesks：減少資料 staleness，但仍可能 race；且引入高 runtime coupling，Distribution 在 HelpDesks 故障時也會掛
• 合併兩個服務：資料一致了，但兩服務多數功能不相關 → 嚴重 local complexity

最終決策：把「pause assignment」抽出 HelpDesks，移到 Distribution。

從平衡耦合的角度：高強度 + 高易變性，被「縮短距離」中和。

Case Study B：從零強度演進到 functional coupling#

Support Case Management 發出新案件事件，Distribution 與 Real-Time Analytics 各自訂閱。

Distribution 為應對尖峰時段，加入了「criticality assessment」邏輯（高優先案、策略客戶、近期升級過的客戶）。

後來 Real-Time Analytics 也需要這個 criticality 值——團隊選擇複製這段邏輯。

結果：原本沒有任何整合強度的兩個元件，變成 symmetric functional coupling，而且距離很遠。

但因為這段邏輯簡單且不太會變（低易變性），團隊接受這個失衡——低 volatility 補償了高 strength + 高 distance。

易變性的變化#

Case Study C：Supporting → Core#

延續上面 criticality 的故事：當「優先處理某些案件」被證明能在尖峰時段提升客戶滿意度，公司決定深入鑽研這個演算法——這代表它從 supporting 升級成 core 子領域。

易變性瞬間從低變高：原本可接受的「重複實作」變成嚴重失衡（高強度 + 高距離 + 高易變性）。

回應：把 criticality 邏輯抽出來放進 Support Case Management——透過消除距離恢復平衡。

Case Study D：Generic → Core#

WolfDesk 一開始用開源 CMS 管理 knowledge base（generic 子領域），Support Case Management 直接寫 CMS 的 operational DB（intrusive coupling）。因為 generic 子領域低易變性，這種 intrusive 耦合勉強可接受。

當 WolfDesk 決定自己做 in-house knowledge management（升級為 core 子領域），易變性大增 → 原本的 intrusive 耦合無法忍受。

回應：新 Knowledge Base 服務只允許透過 API 寫入，且使用整合專用模型——從 intrusive 降到 contract coupling。

距離的變化#

Case Study E：從 Monolith 拆成 Services#

WolfDesk 起初是 monolith，模組之間距離小，介面易於 refactor。隨著公司成長、團隊增加，總架構師決定把 monolith 拆成多個服務、由不同團隊負責。

拆分之後距離變大，連動修改的成本暴增。為了避免 cascading change，團隊得收緊邊界——把某些整合從 model coupling 降到 contract coupling。

不是所有成長都能透過 rebalancing 解決#

有些情況下，調整距離只是把 local complexity 換成 global complexity（或反之）。這類由「成長」帶來的更深層挑戰，是 Chapter 12「Fractal Geometry」要回答的問題。

重點整理#

Tactical 變動該被設計容納；strategic 變動需要主動 rebalancing：

• 強度上升 → 縮短距離，或重構成更弱的整合
• 易變性上升 → 縮短距離或降低強度（視情境）
• 距離拉開 → 收緊強度（從 model 降到 contract）

失衡未被察覺、或察覺後未調整，技術債與意外性複雜度將迅速堆積。

下一章會處理最常見也最危險的策略變動：成長（growth），並引入「碎形幾何」的視角。