現在的大部分 Web 框架都是使用金字塔式的分層架構，一般這種應用都是阻塞同步 IO 模型的程式設計實現，理解這種分層架構模型的實質有助於理解框架。
因為萬變不離其宗，理解這種架構後你不管這種模型如何變化實際上都是在遵守一些約定和規則，那麼理解這個模型，只要這個框架是這種架構那麼你都會掌握的很快。
首先我們從最簡單的 MVC 三層架構說起。
實際上，一般框架分層就是這種分層的，這種分層模型使用時通過一個入口檔案啟動框架服務，註冊一些框架依賴，然後通過路由分發將請求分發到各個控制器裡去，一般邏輯寫在控制器層，模型層做資料處理，檢視層負責展現。
隨著專案變大，協作人數變多，這種分層會不太能適應需求，那麼我們可以通過增加分層來解決問題。
我們在模型層和控制器層中增加服務層，通過依賴注入的方式將控制反轉，能解決擴充套件和重用的問題，但隨著專案繼續擴大，我們又要增加一層。
我們再分一層，將資料修改獲取邏輯放到儲藏庫層，模型只負責模型定義，這樣多個程式設計師就可以工作在不同的層上。
理論上我們可以無限分層，不斷的拆分將業務分層拆的更細。但是有的場景中我們需要做一些操作其實不能很好的分層，因為有的業務可能用到，有的業務可能不會用到，同時由於分層我們製造了許多元件和分層之間的依賴，在這樣的系統中物件導向設計和編碼變的重要。
此時引進了一個新的概念 AOP ，既面向切面程式設計
上圖的藍色就是切面，面向切面程式設計，這種程式設計方法就是在需要的地方實現一個切面，把一些需要做但不是每個業務都要做的東西放到這裡去做，如中介軟體、過濾器、攔截器、事件通知、觀察者都算是這種切面的實現之一。
總結
金字塔分層模型是阻塞 IO 程式設計的常用處理方式。
分層會帶來業務低耦合及增強程式複用性，但同時也會帶來業務邏輯程式碼變得複雜。
物件導向程式設計時為了解決大型專案的複雜性問題而產生的程式設計方法，有些人說這個不重要或者沒有用很有可能是做的專案還不夠大還不夠複雜，或者是根本不涉及到協作開發的原因，亦或者是真的是要使用底層語言做高效能的開發，而語言本身不支援。
金字塔式架構開發，業務平行展開難度較大，這種架構在人員分組上 5-7 人一般會達到極限，此時即使增加人手也不會增加開發速度和效率。解決這個問題的就是微服務或者是扁平化的基於訊息傳遞的面向訊息程式設計。
世界上不止阻塞 IO 程式設計，還有多執行緒、協程，也有非阻塞 IO 非同步程式語言，它們使用的程式設計模型和金字塔分層模型是有區別的，但在理解和使用上難度更高些。