Web 是細節 (The Web Is a Detail)#

在現代開發中，我們常說「我們正在開發一個 Web 應用程式」。這句話本身就暗示了我們把 Web 當作了架構的核心。 Uncle Bob 在這一章再次顛覆了這個觀念：Web 只是一種 GUI，而 GUI 是一個細節。

既然 GUI 是一個細節，那麼 Web 自然也只是一個細節。它不應該主導系統的架構設計。

一、無盡的鐘擺：UI 的演進#

回顧歷史，使用者介面（UI）的架構一直在擺盪：

• 1990s: 所有的邏輯都在伺服器端（Mainframes/Centralized）。
• 2000s: 所有的邏輯都在客戶端（Client-Server/Desktop Apps）。
• 2010s: 所有的邏輯又回到了伺服器端（Web 1.0/2.0）。
• 現在: 邏輯又開始往客戶端移動（SPA, Mobile Apps）。

Web 只是這個鐘擺中的一個過客。如果你的架構與「Web」綁定太深，當下一次 UI 典範轉移發生時（例如變成語音介面或 VR），你就必須重寫整個系統。

二、Web 只是 I/O 設備#

從架構師的角度來看，瀏覽器（Browser）與以前的綠色螢幕終端機（Console）沒有本質區別。 它們都只是 IO 設備（Input/Output Device）。

• Web 的本質： 它負責將使用者的輸入送到伺服器，並將伺服器的輸出顯示給使用者。
• 架構的目標： 業務邏輯應該將 Web 視為一個「外掛」。
  • 業務邏輯不應該知道 HTML 是什麼。
  • 業務邏輯不應該知道 HTTP Header 是什麼。
  • 業務邏輯不應該知道 GET/POST 是什麼。

三、分離策略：使用案例與資料結構#

要如何實現這種分離？關鍵在於使用案例（Use Cases）與資料結構的設計。

1. 純粹的互動： 使用案例將 Web 視為一個黑盒子。它只關心：「給我一個輸入資料結構，我會還給你一個輸出資料結構。」
2. 邊界轉換：
   • Controller 負責將 HttpRequest 轉換為單純的 RequestModel（普通物件）。
   • Use Case 處理 RequestModel，回傳 ResponseModel。
   • Presenter 負責將 ResponseModel 轉換為 HttpResponse 或 HTML。

這樣一來，Use Case 就如同在真空環境中操作，完全獨立於 Web。

四、好處：適應性#

將 Web 視為細節的最大好處是適應性（Adaptability）。

• 情境： 老闆說：「我們的產品很成功，現在我們要出 iOS App 版，而且要有命令行（CLI）管理工具。」
• 結果：
  • 如果你的業務邏輯綁死在 Web Controller 裡，你得重寫三次邏輯。
  • 如果你遵循了整潔架構，你只需要寫新的 UI 層（App View, CLI View），而核心業務邏輯完全不需要修改。

總結： Web 是一種交付機制（Delivery Mechanism），而不是應用程式本身。 別讓 Web 框架（如 Spring MVC, Rails）滲透到你的核心。將其隔離，你將獲得一個壽命比 Web 潮流更長久的系統。