建立完整的架構邊界（Full Architectural Boundaries）是昂貴的。
它需要雙向的多型介面（Reciprocal Polymorphism）、
獨立的輸入/輸出資料結構（Input/Output Data Structures），
以及繁瑣的依賴管理（版本控制、獨立編譯、獨立部署）。
這是個典型兩難：
- YAGNI (You Aren’t Gonna Need It)： 如果現在不需要，過早建立完整邊界是過度設計（Over-engineering）
- 未來擴展： 如果完全沒有邊界，未來需要時再拆分會極其困難
折衷方案就是 「部分邊界（Partial Boundaries）」。
架構師可透過以下三種方式來保留未來可能性，同時降低當下成本。
一、三種部分邊界策略#
| 策略 | 作法 | 優點 | 缺點 |
|---|---|---|---|
| 省略最後一步 | 完成所有程式碼工作，但不分開部署；放在同個元件中 | 結構已分好，未來拆分只需移動類別 | 缺乏編譯器強制力，邊界容易被侵蝕 |
| 單維邊界 (Strategy) | 使用 Service 介面，省略雙向介面 | 結構簡單，實作容易 | 易形成「反向通道」隱性耦合 |
| 外觀模式 (Facade) | 定義 Facade 類別轉發請求，省略 DIP | 隱藏系統複雜性 | 違反 DIP，產生傳遞依賴 |
Figure 24.1: The Strategy pattern
Figure 24.2: The Facade pattern
二、架構師的職責：監控退化#
所有的部分邊界都有個共同風險：退化（Degradation）。
因它們都不是「完整」邊界，隨著時間推移，分離性都會逐漸降低。
- 判斷： 架構師須判斷哪裡需要邊界，以及要實作「完全」還是「部分」邊界
- 監控： 如果選擇部分邊界，架構師須時刻關注其狀態。
一旦發現依賴關係開始混亂（反向通道出現、邊界被侵蝕），就須決定是否將其升級為完整邊界
部分邊界是種「買保險」策略。 它允許你在不支付全額成本（獨立部署）的情況下，獲得大部分的架構優勢（解耦）。
但你須有紀律地維護它，否則它終將崩壞。