會尖叫的架構 (Screaming Architecture)#
想像一下，當你看到一張建築藍圖時，你看到了什麼？ 如果你看到寬敞的入口、櫃檯、大量的書架區和閱讀桌，這張藍圖在對你尖叫：「這是一這圖書館！」 如果你看到廚房、臥室、客廳和車庫，這張藍圖在尖叫：「這是一間房子！」
軟體架構也應該如此。 當你打開專案的最上層目錄時，它應該高聲尖叫出**「這個系統是做什麼的」**，而不是尖叫出它用了什麼框架。
一、你的架構在尖叫什麼？#
不幸的是，現代許多軟體專案的架構並沒有尖叫出業務意圖。 當你打開一個典型的 Web 專案，你通常會看到：
controllers/views/models/helpers/
這張藍圖在尖叫什麼？它在尖叫：「我是 Rails！」 或 「我是 Spring！」 或 「我是 ASP.NET！」 它並沒有告訴你這個系統是用來做會計、醫療還是電子商務的。
核心觀點： 架構應該是關於系統的使用案例（Use Cases），而不是關於框架。 一個良好的架構，應該讓人在不看實作細節的情況下，就能一眼看出系統的業務功能。
二、框架是工具，不是生活方式#
框架（Frameworks）非常強大，也非常有用。但架構師必須保持清醒：框架只是工具，它不該接管你的架構。
- 主從關係： 你的架構應該使用框架，而不是被框架所「擁有」。
- 保持距離： 不要讓框架滲透到你的核心業務邏輯中。不要讓你的實體（Entities）繼承框架的基底類別。
- 各司其職： 網頁（Web）只是一種交付機制（Delivery Mechanism），就像 Console app 也是一種交付機制一樣。你的應用程式架構應該把 Web 視為一個細節、一個 I/O 裝置，而不是核心。
三、原地測試 (Testable In-Place)#
如果不依賴框架，會帶來什麼好處？最大的好處是可測試性。
- 脫離環境： 系統中的核心邏輯應該能夠在「原地」被測試，而不需要啟動 Web 伺服器、不需要連接資料庫、不需要複雜的環境配置。
- 單純的物件： 既然你的使用案例物件只是普通的物件（Plain Objects），你應該能寫出簡單的單元測試來驗證它們。
- 解耦驗證： 測試應該針對業務規則是否正確，而不是測試 HTTP Request 是否有正確傳遞。
總結： 如果你的架構設計得當，當新進人員加入團隊時，他們看著原始碼結構會說： 「喔，這是一個庫存管理系統。」 而不是說：「喔，這是一個 MVC 架構的網站。」