框架是細節 (Frameworks Are Details)#

框架（Frameworks）非常流行。它們通常是免費的、強大的，並且由社群維護。看起來使用它們是理所當然的選擇。但 Uncle Bob 給出了一個嚴厲的警告： 「你可以使用框架，但不要與它結婚。」

一、不對等的婚姻 (The Asymmetrical Marriage)#

使用一個框架，就像是進入一段沒有對等承諾的婚姻。

你的承諾： 你為了使用這個框架，大量引用它的基底類別、使用它的標記（Annotations）、遵循它的生命週期。你對它做出了巨大的承諾，將你的專案與它緊緊綁在一起。
它的態度： 框架作者對你沒有任何承諾。他們是為了解決他們的問題而寫的，不是為了解決你的問題。
- 他們不會打電話問你：「我們要改這個 API，會影響你嗎？」
- 他們會為了自己的發展方向，毫不留情地更改功能，甚至讓你的程式碼無法運作。

當你讓框架滲透到架構的核心（內圈）時，你會面臨以下風險：

架構不整潔： 框架通常要求你繼承它們的類別（例如 extends FrameworkController）。這違反了依賴規則，導致你的業務規則與框架細節產生強烈耦合。
需求衝突： 框架的發展方向可能與你的產品需求背道而馳。你需要的功能被移除了，你不需要的功能卻讓系統變慢了。
喜新厭舊： 總會有更新、更酷的框架出現。如果你與舊框架綁得太死，當你想換框架時，你會發現自己動彈不得。

我們不是不使用框架（那太愚蠢了），而是要聰明地使用。

不要讓框架進入內圈：
- 業務實體（Entities）不應該有 @Entity (Hibernate annotation)。
- 使用案例（Use Cases）不應該有 @Autowired (Spring annotation)。
使用轉接器 (Adapters)：
- 將框架視為一個細節（Detail）。
- 讓框架留在架構的最外圈（藍色圈）。
- 建立一個**轉接器（Proxy/Adapter）**來整合框架，並將其作為插件（Plugin）插入核心程式碼。

總結： 與框架保持一種**「單向約會」**的關係。你可以利用它的功能，但要隨時保持「能夠甩掉它」的能力。將框架擋在架構邊界之外，不要讓它接管你的應用程式。