設計一個架構，面臨的首要問題是如何進行分解，分解后的組件相互如何組織在一起。從這個意義上說，架構有很多種，而最典型并且在企業中應用最廣泛的非分層架構莫屬了。分層架構直觀來講就是一種“分層蛋糕”，每一層都依托在其下層之上，上層使用下層定義的各種服務，而下層對上層一無所知。這方面的例子非常多，例如計算機本身分成硬件抽象層，操作系統層，系統軟件和應用軟件層，互聯網ISO 7層架構等等。這也印證了一句名言--“計算機中的任何問題都可以通過增加一個中間層來解決”。
分層架構具有很多優勢：
- 上層無需了解下層的實現細節，每一層都是一個有機整機；例如無需了解以太網如何運行，你依然可以用TCP/IP協議來編寫FTP服務。這一點對于廣大技術人員尤其是程序員至關重要，否則我們每次編寫應用的時候都既要知道硬件、又要了解操作系統，還要懂編譯器
- 下層可以實現透明的替換，只要替換前后提供相同的服務接口。例如FTP服務可以運行在PPP上，也可以運行在以太網上
- 層次之間的依賴很小，例如只要TCP/IP協議不變，FTP服務就不變，無論數據鏈路和物理層發生怎樣的變化
- 分層明確了了每層的功能和接口，有利于進行標準化
- 下層可以為上層多個服務提供支持，只要服務遵循相同的調用接口
分層架構同時也有自身的缺陷，主要有以下兩點：
- 層次不能封裝所有的東西，最典型的代表就是如果要在用戶界面顯示增加一個數據域，則數據庫中需要增加相應的字段，并且業務層也需要做相應的修改。
- 過多的層次會加大調用開銷，從而影響性能。
企業應用架構的演變經過了以下幾個階段（主要是指單個應用的架構）:
- 兩層架構 - 以客戶機/服務器系統為代表，客戶端（胖客戶端）負責用戶界面和業務邏輯，服務器就是關系型數據庫。常見的工具有VB，PowerBuider等，一般來說這個階段業務比較簡單，主要就是數據庫的增刪改查，通過用戶界面上的SQL感知控件來連接和操作數據庫。
- 三層架構 - 我認為也可以稱為四層架構（如果算上數據庫），即表現層、領域層和數據源層。表現層用來處理與用戶的交互，可以是命令行、胖客戶端或者web界面；數據源層主要關注和其它系統的交互，如數據庫、消息系統、緩存或其它；領域層主要負責執行領域邏輯，完成相關的計算。
在本系列中，我們主要關注分層架構，至于后來出現的SOA和微服務架構，以及驅動這些架構出現的原因，會在另外的文章中分析。
另外，對于三層架構，我們需要注意以下幾點：
- 三層架構的每一層可以在垂直方向上進行再拆分，形成不同的軟件包，例如表現層分為命令行和web界面，數據源層分為數據庫、文件系統等
- 在實際應用中，下層對于不相鄰的上層并不是完全透明的，例如有時為了效率或其它考慮，可能會從表現層直接訪問數據源層
- 分層架構指的是邏輯上的分層，而從物理上來看，可以有多種部署架構。例如Java中可以三層都放在同一個JVM（Tomcat）中；也可以把表現層放在Tomcat中，而業務邏輯放在JBoss EJB（另外一個JVM，甚至是不同的服務器）中。