想像一下，當你看到一張建築藍圖時，你看到什麼？
如果你看到寬敞入口、櫃檯、大量書架區和閱讀桌，這張藍圖在對你尖叫：「這是一個圖書館！」
如果你看到廚房、臥室、客廳和車庫，這張藍圖在尖叫：「這是一間房子！」
軟體架構也應該如此。
當你打開專案最上層目錄時，它應高聲叫出 「這系統是做什麼的」，而不是尖叫它用了什麼框架。
一、你的架構在尖叫什麼？#
不幸的是，現代許多軟體專案架構並沒有叫出業務意圖。 當你打開一個典型的 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 架構的網站。」