邊界：畫線 (Boundaries: Drawing Lines)#

軟體架構就是一門「畫線」的藝術。 我們在軟體元素之間劃出邊界，將其隔離。這些線的目的是為了將「策略（Policy）」與「細節（Details）」分開。

• 策略： 核心業務規則（重要）。
• 細節： 資料庫、Web 框架、GUI（相對不重要，只是機制）。

一、為什麼要畫線？為了「推遲決定」#

畫線的最主要戰略價值，在於它讓我們能夠**推遲（Defer）**關於細節的決定。

• 過早決定的代價： 許多專案在初期就決定了「我們要用 MySQL」或「我們要用 React」。這時我們對系統需求的了解最少，往往做出次佳的選擇。
• 架構師的勝利： 一個好的架構設計，能讓你把這些決定推遲到專案的中後期。
  • 你可以先寫好所有的業務邏輯，用「假」的資料庫（Mock）來測試。
  • 直到最後一刻，你才需要決定真正的資料庫是什麼。這大幅節省了因為選錯技術而重構的時間。

二、邊界的法則：依賴方向#

這條線該怎麼畫？規則很簡單：將線畫在「重要事物」與「不重要事物」之間。

• GUI vs. 業務規則： 業務規則對 GUI 是什麼一點興趣都沒有。GUI 是不重要的（它只是 I/O 通道），業務規則是重要的。
• 資料庫 vs. 業務規則： 資料庫只是儲存資料的工具（細節），業務規則不該知道資料庫的存在。

依賴箭頭的鐵律： 依賴關係的箭頭，必須永遠由「細節」指向「抽象」（由低層級指向高層級）。

• GUI $\rightarrow$ 依賴 $\rightarrow$ 業務規則
• Database $\rightarrow$ 依賴 $\rightarrow$ 業務規則

三、外掛架構 (Plugin Architecture)#

Uncle Bob 在此回顧了軟體開發的歷史，得出了一個結論：

% 「軟體開發的歷史，就是『如何輕易建立外掛（Plugin）』的歷史。」

• 不對稱關係： 系統元件間的關係是極度不對稱的。
  • 核心系統（業務規則）對外掛（GUI/DB）免疫。
  • 外掛對核心系統高度依賴。
• 應用： 我們應該將 GUI 視為業務規則的 Plugin；將 Database 視為業務規則的 Plugin。
• 好處： 既然是 Plugin，就意味著可插拔（Swappable）。我們可以隨時把 Web GUI 換成 Console GUI，或把 SQL DB 換成 NoSQL DB，而完全不影響核心業務邏輯。

總結： 架構師的工作就是畫出邊界，讓系統的核心邏輯保持純淨。 透過將細節視為外掛，我們不僅保護了核心，更贏得了「在擁有最多資訊時才做決定」的權利。