一、架構模式
除了通常應用於對象和類之間交互的典型設計模式和原則之外，還有一些從總體上指導架構的原則或模式。《面向模式的軟件體系結構》中將它們定義爲架構模式，而不是設計模式。本文將介紹其中兩種模式：層與MVC。
但將它們成爲“模式”會讓某些人的理解受到一定限制，他們會把它們看做是死規定而不是指導。其實，將它們看做整體概念、範型或分類原則可能更有效。理解和記住它們要比嚴格地應用它們重要——eg. 引入層或者MVC在非常簡單的Web應用中顯然沒有必要。
二、分層設計
“分層”的理念是構建軟件時普遍和自然的思考方式。函數、方法或者對象有啄序（pecking order）之分：函數A“啄”（調用）函數B的次數比函數B“啄”函數A的次數多，因此函數B在啄序中的等級低於函數A。如果你的代碼中這種情況很多，可以將代碼整理成層，對它們進行分類。就像所有這些組件都漂浮在周圍一樣，你需要抓住它們，將它們放到不同的架子上，方便組織和記憶。
在精確分層的架構中，每層上的對象都只能方位低於它所在層上的對象。網絡協議就是這種方式。
- “三層”模式
分層設計有些像等級制企業或者軍事機構，給系統中的每個組件一個“等級”即爲啄序，這樣可以吩咐較低級別的組件要做什麼。
典型的三層架構如下：
eg. 與數據庫有關的類，提供non-SQL接口給數據層其他類 |
以上，一個不太嚴格的示例可能就是 ActiveRecord 模式，其中業務邏輯和數據存儲邏輯都混合在一個類中。
- 邏輯層（域層）
域層的功能可以用CRUD來概括。如果有複雜的業務邏輯，域對象就會非常有用。反之，如果爲當前並不需要的需求引入它的話，只會增加系統的負擔。
有關面向對象的書籍通常着重介紹域層，將其作爲複雜邏輯存在的地方。但在Web應用程序中，最複雜的邏輯通常存在於程序的其它的地方。
多數企業的應用程序中使用的基本設計都是分層設計。對高級別的關注點進行分離，讓多數更改隻影響一層，實現單一職責原則。
三、MVC
MVC體系結構基於表現層和邏輯層分離。而在MVC術語中，它是模型（model）和視圖（view）的分離。當然，還有第二個分離，視圖和控制器之間的。
在MVC中，model是程序的功能核心，view用於向用戶展示信息，controller用來處理用戶輸入。
下圖簡要說明Web MVC如何工作。箭頭意爲：使用。
下表概括了MVC結構中各個組件的作用：
將MVC視爲一種原則更爲有用一些。模型、視圖和控制器不比分在不同的類或者函數中，每個部分聚合一起，而不是隨意地散落在應用程序各處，這是MVC最重要的特性。
- 控制器邏輯
Web原本就是帶有超鏈接的靜態HTML頁面的集合。用戶通過在瀏覽器中輸入URL或者點擊鏈接（GET）請求特定頁面，並且只獲取該頁面。
處理（POST）請求是增加Web編程複雜程度的元兇，這也就是Web應用引用MVC的原因。
如果用戶請求並未指定用戶要看什麼內容，這時候程序需要作出決定（決定顯示什麼視圖）。這一功能不屬於業務邏輯，因此不屬於模型的一部分。而關於顯示哪個視圖的決策一個視圖自然無法完成。能做到這點只有控制器。
四、總結
MVC是成功的手段，而不是標準。如果要評估一個設計，我們不應該關心這個設計是否符合MVC，而更需關注的是：代碼的可讀性如何？是否好理解？有沒有重複現象？是否可靠？是否有恰當的靈活性？MVC不是萬能的，它有最重要的定義：處理用戶輸入和輸出。
某種程度上，分層可能比MVC更通用，而且更像範型。要讓所有細節都符合模式是沒有多大益處的。