本章內容出自《軟件架構模式》第一章，該書由 開發技術前線 項目組成員翻譯，更多內容請訪問 《軟件架構模式》中文版pdf 。
簡介
對程序員來說很常見一種情況是在沒有合理的程序架構時就開始編程，沒有一個清晰的和定義好的架構的時候，大多數開發者和架構師通常會使用標準式的傳統分層架構模式（也被稱爲多層架構）——通過將源碼模塊分割爲幾個不同的層到不同的包中。不幸的是，這種編碼方式會導致一系列沒有組織性的代碼模塊，這些模塊缺乏明確的規則、職責和同其他模塊之間的關聯。這通常被稱爲架構大泥球。
應用程序缺乏合理的架構一般會導致程序過度耦合、容易被破壞、難以應對變化，同時很難有一個清晰的版本或者方向性。這樣的結果是，如果你沒有充分理解程序系統裏每個組件和模塊，就很難定義這個程序的結構特徵。有關於程序的部署和維護的基本問題都難以回答，比如：程序架構是什麼規模?應用程序有什麼性能特點?應用程序有多容易應對變化?應用程序的部署特點是什麼?架構是如何反應的?
架構模式幫助你定義應用程序的基本特徵和行爲。例如，一些架構模式會讓程序自己自然而然地朝着具有良好伸縮性的方向發展，而其他架構模式會讓程序朝着高度靈活的方向發展。知道了這些特點，瞭解架構模式的優點和缺點是非常必要的，它幫助我們選擇一個適合自己特定的業務需求和目標的的程序。
作爲一個架構師,你必須證明你的架構模式的決策是正確的,特別是當需要選擇一個特定的體系結構模式或方法的時候。這本迷你書的目的就是給你足夠的信息讓你去做出正確的架構決策。
第一章 分層架構
分層架構是一種很常見的架構模式，它也叫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來實現用戶和訂單數據的訪問模塊。
注意事項
分層架構是一個很可靠的架構模式。它適合大多數的應用。如果你不確定在項目中使用什麼架構，分層架構是再好不過的了。然後，從架構的角度上來說，選擇這個模式還要考慮很多的東西。
第一個要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。
在這個模式中，請求流只是簡單的穿過層次，不留一點雲彩，或者說只留下一陣青煙。比如說界面層響應了一個獲得數據的請求。響應層把這個請求傳遞給了業務層，業務層也只是傳遞了這個請求到持久層，持久層對數據庫做簡單的SQL查詢獲得用戶的數據。這個數據按照原理返回，不會有任何的二次處理，返回到界面上。
每個分層架構或多或少都可能遇到這種場景。關鍵在於這樣的請求有多少。80-20原則可以幫助你確定架構是否處於反污水模式。大概有百分之二十的請求僅僅是做簡單的穿越，百分之八十的請求會做一些業務邏輯操作。然而，如果這個比例反過來，大部分的請求都是僅僅穿過層，不做邏輯操作。那麼開放一些架構層會比較好。不過由於缺少了層次隔離，項目會變得難以控制。
模式分析
下面的的表裏分析了分層架構的各個方面。
整體靈活性
評級:低
分析:總體靈活性是響應環境變化的能力。儘管分層模式中的變化可以隔絕起來，想在這種架構中做一些也改變也是並且費時費力的。分層模式的笨重以及經常出現的組件之間的緊耦合是導致靈活性降低的原因。
易於部署
評級:低
分析:這取決於你怎麼發佈這種模式，發佈程序可能比較麻煩，尤其是很大的項目。一個組件的小小改動可能會影響到整個程序的發佈(或者程序的大部分)。發佈必須是按照計劃，在非工作時間或者週末進行發佈。因此。分層模式導致應用發佈一點也不流暢，在發佈上降低了靈活性。
可測試性
評級:高
分析:因爲組件都處於各自的層次中，可以模擬其他的層，或者說直接去掉層，所以分層模式很容易測試。開發者可以單獨模擬一個展示組件，對業務組件進行隔絕測試。還可以模擬業務層來測試某個展示功能。
性能
評級:低
分析:儘管某些分層架構的性能表現的確不錯，但是這個模式的特點導致它無法帶來高性能。因爲一次業務請求要穿越所有的架構層，做了很多不必要的工作。
伸縮性
評級:低
分析:由於這種模式以緊密耦合的趨勢在發展，規模也比較大，用分層架構構建的程序都比較難以擴展。你可以把各個層分成單獨的物理模塊或者乾脆把整個程序分成多個節點來擴展分層架構，但是總體的關係過於緊密，這樣很難擴展。
易開發性
評級:容易
分析:在開發難度上面，分層架構得到了比較高的分數。因爲這種架構對大家來說很熟悉，不難實現。大部分公司在開發項目的都是通過層來區分技術的，這種模式對於大多數的商業項目開發來說都很合適。公司的組織架構和他們軟件架構之間的聯繫被戲稱爲”Conway’s law”。你可以Google一下查查這個有趣的聯繫。
