原文地址  譯者：克里斯托劉

第一章

分層架構

最通常的架構模式就是分層架構模式，即所謂的N層架構。這種模式對大部分JAVAEE應用程式來說是標準模式，因此被大部分架構師、軟體設計師、開發者廣泛知曉。由於分層架構模式和公司裡傳統的IT溝通以及組織結構非常類似，使得它成為大多數商務應用開發最自然的選擇。

模式描述

在分層架構模式中，它將應用分成多個水平層，每個水平層在應用中擔任一個專門的角色（比如表現層或者業務邏輯）。儘管分層架構模型並沒有指定必須的層次個數以及型別，但大部分這種模型都由4個標準層次構成：表現層、業務層、持久層、資料庫（圖1）。在一些情況下，業務層和持久層可以合為一個單一的業務層中，特別是當持久層的邏輯（比如SQL或者HSQL）內嵌於業務層中。因此小應用程式通常只有三個層‑次，至於更大或者更多的複雜商業應用可能會包含5個或者更多的層次。在此架構中每層都有一個特定的角色和責任。比如，表現層負責處理所有使用者互動和瀏覽器溝通的邏輯，業務層可能會負責執行和要求相關的特定業務。在分層架構中，每一層只需要圍繞滿足特定業務請求的工作形成抽象。比如表現層不需要了解或關心如何獲取客戶資料；它只需要按特定格式展示資訊；同理，業務層也無需關心如何展示客戶資料，甚至業務層都無需知道客戶資料從哪裡來；業務層只需要從持久層獲取資料，運用這些資料執行業務邏輯，再把資訊上傳給表現層。

這種模型一個強大的特徵是隔離開元件按照不同層次。每個層次中的元件只需要處理屬於那個層次的功能邏輯即可。比如在展示層的元件只需要處理展示的邏輯，而業務層中的元件只需要處理業務邏輯。這樣的元件分類方式便於建立高效的角色和責任制的模型，同時也會方便開發、測試、管理、維護應用，因為設計完善的元件介面以及限制的元件功能範圍。

關鍵概念

注意在圖1-2中，架構中的每個層次被標記為封閉狀態。在該架構模式中，這是一個非常重要的概念。一個封閉的層次意味著當需要把訊息從一層傳遞給另一層時，它必須先通過位於第一層正下方的那層，才能達到再下面的一層。例如，一個來自於表現層的要求，必須先通過業務層、持久層才最終到達資料庫。

那麼為什麼不讓表現層直接到達資料庫呢？這樣速度會更快。這裡就牽涉到了一個關鍵概念叫層次分離。

層次分離意味著不同層次間互不影響，你在一個層次上的改動不會影響其他層次。如果你讓表現層能直接訪問持久層，會導致任何在持久層SQL上面的改動既會影響業務層也會影響表現層，這造成了應用中不同元件之間的強耦合影響，這樣的應用架構也會變得難以修改。

層次分離也意味著不同層次間相對獨立，因此不需要知道另一個層次的內部實現。理解這一點，考慮一個把表現層架構從JSP轉換成JSF的大型重構專案，假設表現層和業務層間的協議不變，那麼業務層不受重構的影響，不會受表現層架構改變的影響。

閉合的層次達成層次分離，會有助於不同層間互不影響，但是也有需要層次開放的時候。例如，假設在一個架構中，有一些需要被業務層次的通用服務元件，因此你想要加一個共享服務層。在種情況，建立一個服務層通常是一個好辦法。因為架構上，它限制了訪問這些共享服務層的必須是業務層而不是表現層。如果沒有一個單獨的服務層，在架構上就不會限制表現層對其的訪問，這樣也會造成管理訪問許可權變得困難。

在這個例子中，新服務層位於業務層下，意味著表現層不能直接訪問該層。然後新的問題是，業務層需要穿越新服務層才能到達持久層，這不符合邏輯。實際上，這個問題可以通過設定開放層次解決。

在圖1-3所示，服務層被標誌成開放狀態，意味著業務層允許跨越這層而直接訪問持久層。這在邏輯上是相符的。

藉助閉環或者開環層次的概念幫助我們定義架構中層次間的關係以及方向流，同時提供給設計者和開發師必要的資訊去理解不同層次的訪問限制。沒有記錄或者沒能和層間合適地溝通通常會導致過緊的耦合以及脆弱的難以測試、維護、部署的架構。