前言
案例1
阿宏最近看了一張室內設計圖並有興趣購買，你覺得他是想開一間餐廳、運動場還是想幹什麼呢?
案例2
看了底下某個專案目錄，你想到了什麼?
(前端)
(後端)
架構的主題
軟體架構是支援系統使用案例的結構，就像住宅或圖書館的平面圖會對「這些建築物的使用案例」尖叫那樣，軟體的應用程式架構也應該對「應用程式的使用案例」尖叫。
架構不是(或不應該是)關於框架的，框架是工具，框架不是架構要順應的對象，如果你的架構是基於框架的，那它就不能基於你的使用案例。
架構的目的
良好的架構會以使用案例為中心去設計，且不必對框架、工具、環境做出承諾，想想房屋的平面圖案例，建築師最關心的問題是確保房子是可用的，而不是確保房子是磚頭做成的，事實上，建築師要努力確保屋主可以在平面圖能確保滿足使用案例後，才對於外部材料(磚、石材、柏木)做出決定。
架構應該使框架是保持開放的選項，一個好的架構會讓專案直到後期之前都不需要對於採用框架、資料庫、Web服務器及其他環境問題(K8S? VM?)做出決定，架構強調的是使用者案例!
但是Web呢?
Web是架構嗎? 當然不是，Web只是一種交付機制 - 是一種IO設備，事實上，你的系統該如何被交付出去(或如何輸出結果)，這應該是最後才決定的事情!
悲慘案例
阿宏的公司很喜歡用winform這種桌面應用程式框架實作系統給User使用(輸出系統結果)，由於User的電腦環境千奇百怪，於是出現各種奇怪的報案(不能安裝、不能開啟、不能上傳檔案，轉圈圈很久)，有天老闆終於受不了了，希望我們全面轉Web，經工程師討論後我們發現...這需要極大的成本...。原因: 沒有包成套件也沒有採用API，我們一開始就將「框架」跟「架構」綁在一起，所以只要動到GUI就會動到Business logic。
框架是工具，不是存在的方式
框架真的是太好用了，好用到你會讓它影響你的架構，看看前面winform的例子，由於它確實可以很快拉出一個版面，也正是因為這種方便，讓人們忽略應該把Business logic拆分出來，以為做任何系統都可以以這種低成本的方式製作，進而不斷產生一堆技術債...
可測試的架構
如果你的系統架構是關於使用案例的，且如果對框架保持一定的安全距離，那應該可以在沒有任何框架的情況下，對所有這些使用者案例做單元測試，你不需要在Web伺服器下運行你的測試，你也不必在連接資料庫的時候做測試，Entity應該是只依賴最原生套件(最純粹)所開發的物件，這樣，你的架構才是一個可測試的架構。
總結
你的架構應該告訴閱讀者關於這個系統的事情(Business)，而不是你系統中所使用的框架、Web服務器或是資料庫。