概述

今天的內容主要來自《軟件架構模式》第一章，覺得還不錯，所以分享給大家。

分層架構

分層架構是一種很常見的架構模式，它也叫N層架構。這種架構是大多數Jave EE應用的實際標準，因此很多的架構師，設計師，還有程序員都知道它。許多傳統IT公司的組織架構和分層模式十分的相似。所以它很自然的成為大多數應用的架構模式。

模式分析

分層架構模式里的組件被分成幾個平行的層次，每一層都代表了應用的一個功能(展示邏輯或者業務邏輯)。盡管分層架構沒有規定自身要分成幾層幾種，大多數的結構都分成四個層次:展示層，業務層，持久層，和數據庫層。如表1-1，有時候，業務層和持久層會合并成單獨的一個業務層，尤其是持久層的邏輯綁定在業務層的組件當中。因此，有一些小的應用可能只有3層，一些有著更復雜的業務的大應用可能有5層或者更多的分層。

分層架構中的每一層都著特定的角色和職能。舉個例子，展示層負責處理所有的界面展示以及交互邏輯，業務層負責處理請求對應的業務。架構里的層次是具體工作的高度抽象，它們都是為了實現某種特定的業務請求。比如說展示層并不需要關心怎樣得到用戶數據，它只需在屏幕上以特定的格式展示信息。業務層并不關心要展示在屏幕上的用戶數據格式，也不關心這些用戶數據從哪里來。它只需要從持久層得到數據，執行與數據有關的相應業務邏輯，然后把這些信息傳遞給展示層。

分層架構的一個突出特性是組件間關注點分離 (separation of concerns)。一個層中的組件只會處理本層的邏輯。比如說，展示層的組件只會處理展示邏輯，業務層中的組件只會去處理業務邏輯。多虧了組件分離，讓我們更容易構造有效的角色和強力的模型。這樣應用變的更好開發，測試，管理和維護。

關鍵概念

注意表1-2中每一層都是封閉的。這是分層架構中非常重要的特點。這意味request必須一層一層的傳遞。舉個例子，從展示層傳遞來的請求首先會傳遞到業務層，然后傳遞到持久層，最后才傳遞到數據層。

那么為什么不允許展示層直接訪問數據層呢。如果只是獲得以及讀取數據，展示層直接訪問數據層，比穿過一層一層來得到數據來的快多了。這涉及到一個概念:層隔離。

層隔離就是說架構中的某一層的改變不會影響到其他層:這些變化的影響范圍限于當前層次。如果展示層能夠直接訪問持久層了，假如持久層中的SQL變化了，這對業務層和展示層都有一定的影響。這只會讓應用變得緊耦合，組件之間互相依賴。這種架構會非常的難以維護。

從另外一個方面來說，分層隔離使得層與層之間都是相互獨立的，架構中的每一層的互相了解都很少。為了說明這個概念的牛逼之處，想象一個超級重構，把展示層從JSP換成JSF。假設展示層和業務層的之間的聯系保持一致，業務層不會受到重構的影響，它和展示層所使用的界面架構完全獨立。

然而封閉的架構層次也有不便之處，有時候也應該開放某一層。如果想往包含了一些由業務層的組件調用的普通服務組件的架構中添加一個分享服務層。在這個例子里，新建一個服務層通常是一個好主意，因為從架構上來說，它限制了分享服務訪問業務層(也不允許訪問展示層)。如果沒有隔離層，就沒有任何架構來限制展示層訪問普通服務，難以進行權限管理。

在這個例子中，新的服務層是處于業務層之下的，展示層不能直接訪問這個服務層中的組件。但是現在業務層還要通過服務層才能訪問到持久層，這一點也不合理。這是分層架構中的老問題了，解決的辦法是開放某些層。如表1-3所示，服務層現在是開放的了。請求可以繞過這一層，直接訪問這一層下面的層。既然服務層是開放的，業務層可以繞過服務層，直接訪問數據持久層。這樣就非常合理。

開放和封閉層的概念確定了架構層和請求流之間的關系，并且給設計師和開發人員提供了必要的信息理解架構里各種層之間的訪問限制。如果隨意的開放或者封閉架構里的層，整個項目可能都是緊耦合，一團糟的。以后也難以測試，維護和部署。

實例

為了演示分層架構是如何工作的，想象一個場景，如表1-4，用戶發出了一個請求要獲得客戶的信息。黑色的箭頭是從數據庫中獲得用戶數據的請求流，紅色箭頭顯示用戶數據的返回流的方向。在這個例子中，用戶信息由客戶數據和訂單數組組成(客戶下的訂單)。

用戶界面只管接受請求以及顯示客戶信息。它不管怎么得到數據的，或者說得到這些數據要用到哪些數據表。如果用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委托(Customer Delegate)模塊。這個模塊能找到業務層里對應的模塊處理對應數據(約束關系)。業務層里的customer object聚合了業務請求需要的所有信息(在這個例子里獲取客戶信息)。這個模塊調用持久層中的 customer dao 來得到客戶信息，調用order dao來得到訂單信息。這些模塊會執行SQL語句，然后返回相應的數據給業務層。當 customer object收到數據以后，它就會聚合這些數據然后傳遞給 customer delegate,然后傳遞這些數據到customer screen 展示在用戶面前。

從技術的角度來說，有很多的方式能夠實現這些模塊。比如說在Java平臺中，customer screen 對應的是 (JSF) Java Server Faces ,用 bean 組件來實現 customer delegate。用本地的Spring bean或者遠程的EJB3 bean 來實現業務層中的customer object。上例中的數據訪問可以用簡單的POJP’s(Plain Old Java Objects)，或者可以用MyBatis，還可以用JDBC或者Hibernate 查詢。Microsoft平臺上，customer screen能用 .NET 庫的ASP模塊來訪問業務層中的C#模塊，用ADO來實現用戶和訂單數據的訪問模塊。

軟件架構設計之分層架構（三層架構）

在軟件體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：數據訪問層、業務邏輯層（又或稱為領域層）、表示層。

各層的作用：

1：數據訪問層：主要是對非原始數據（數據庫或者文本文件等存放數據的形式）的操作層，而不是指原始數據，也就是說，是對數據庫的操作，而不是數據，具體為業務邏輯層或表示層提供數據服務．

2：業務邏輯層：主要是針對具體的問題的操作，也可以理解成對數據層的操作，對數據業務邏輯處理，如果說數據層是積木，那邏輯層就是對這些積木的搭建。

3：界面層：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表現成：aspx，如果邏輯層相當強大和完善，無論表現層如何定義和更改，邏輯層都能完善地提供服務。

區分方法：

1：數據訪問層：主要看數據層里面有沒有包含邏輯處理，實際上它的各個函數主要完成各個對數據文件的操作。而不必管其他操作。

2：業務邏輯層：主要負責對數據層的操作。也就是說把一些數據層的操作進行組合。

3：界面層：主要對用戶的請求接受，以及數據的返回，為客戶端提供應用程序的訪問。

總結

分層架構是一個很可靠的架構模式。它適合大多數的應用。如果你不確定在項目中使用什么架構，分層架構是可以先用著的。不過從架構的角度上來說，選擇這個模式還要考慮很多的東西（如污水池反模式）。后面會分享更多devops和DBA方面的內容，感興趣的朋友可以關注一下~