Clean Architecture：SOLID 原則與依賴邊界

架構與設計沒有本質區別，兩者都是「軟體整體計畫」的一部分，差別只在決策的層次。而所有架構工作服務的是同一個目標：讓系統易於改變。一套好架構能讓你在需求變動時，用最小的代價、最少的重工去回應——這比讓系統「現在正確運作」更難、也更持久地重要。

• 軟體有兩種價值：行為價值與架構價值。行為價值是「讓系統做對事」，架構價值是「讓系統易於改變」。多數人只盯著前者，但 Uncle Bob 主張後者往往更關鍵：一個功能正確卻硬到改不動的系統，會隨每次需求變更而愈發昂貴，最終價值歸零。
• 三種程式設計典範各是一種「紀律」。結構化程式設計取消了 goto（限制直接控制轉移）、物件導向限制了間接控制轉移、函數式限制了賦值。它們不是給你新能力，而是拿走你的能力——正是這些限制，讓大規模架構的紀律成為可能。
• SOLID 五原則從類別層級一路適用到架構層級。SRP（單一職責，一個模組只對一個角色負責）、OCP（開放封閉，靠擴充而非修改來因應變化）、LSP（里氏替換，子型別要能無痛替換父型別）、ISP（介面隔離，別逼客戶依賴用不到的東西）、DIP（依賴反轉，依賴抽象而非具體）。
• 依賴反轉是整潔架構的引擎。DIP 讓你可以「反轉」原始碼依賴的方向——即使控制流從高階流向低階，原始碼依賴仍能一致指向高階。這使得跨越邊界時，依賴永遠指向更穩定、更抽象的一側。
• 依賴規則：原始碼依賴只能指向內層。以同心圓表示——最內是 Entities（企業規則），往外是 Use Cases（應用規則）、Interface Adapters、Frameworks & Drivers。內層對外層一無所知；外層的變化不應波及內層。
• 資料庫、Web、框架都是「細節」。它們位於最外圈，是可抽換的插件，而非架構核心。把商業規則與這些細節解耦，你就能延後決策、獨立測試、並在細節過時時替換它們，而不動到系統的心臟。

⚖️ 為什麼「架構價值」比「行為價值」更難也更重要

急著上線的團隊幾乎總是犧牲架構、保住行為——因為老闆看得見功能，看不見結構。但這個取捨的帳，會在往後每一次變更時被追討。

🖼️ 依賴規則怎麼在真實系統裡運作

想像一個典型的請求流：Web 送進來一筆資料，經過 Controller，呼叫 Use Case（應用商業規則），Use Case 操作 Entity（企業商業規則），再把結果透過 Presenter 送回 Web。控制流從外向內、再從內向外；但「原始碼依賴」——也就是誰 import 誰、誰認識誰——必須始終指向內。Use Case 不知道 Controller 存在，Entity 不知道資料庫存在。

要讓控制流與依賴方向「相反」，靠的正是 DIP：在邊界上放一個由內層定義的介面，外層去實作它。於是 Use Case 呼叫的是它自己擁有的 Gateway 介面，真正的 SQL 實作住在外圈，實作方向內依賴。這帶來三個具體好處：其一，商業規則可以在沒有資料庫、沒有 UI、沒有框架的情況下被單元測試；其二，你可以把 Oracle 換成 Postgres、把 Web 換成桌面，而不動核心；其三，團隊可以沿邊界並行開發。書末的案例研究把這套規則落到影片販售、真實專案的目錄結構上，示範「按元件的變更軸切分」而非「按技術分層堆疊」，讓每個元件能獨立內聚、獨立部署。

• 架構的目標是讓系統「易於改變」；架構價值往往比一時的行為價值更關鍵。
• SOLID 不只管類別：SRP 定義邊界、DIP 反轉依賴，是整潔架構得以成立的兩根支柱。
• 依賴規則只有一條——原始碼依賴永遠指向內層的高階策略，內層對外層一無所知。
• 資料庫、Web、框架都是可抽換的細節；把它們隔到外圈，才能延後決策、獨立測試、自由替換。
• 延伸：系統層級的整潔，源自每個檔案、每個函式的整潔紀律，回到 Clean Code：什麼是整潔的程式碼。