應用軟體的層次劃分

談到應用程式的層次，我們平時所說的層次有兩種：邏輯的層次（layer）和部署的層次（tier）。這兩種層次劃分的目的是不同的，因此劃分方式也有一些差異，能夠為應用程式帶來的好處也是不同的。

邏輯層次

邏輯層次（layer）劃分的最重要的目的在於調整應用程式各部分之間的依賴關係。應用程式可以看作資料和商務規則的集合，這個集合通過使用者介面與使用者發生互動。如果不劃分層次，或者只劃分最簡單的層次，系統的結構就會是這樣：資料庫處於系統的中心地位，在此之上建立使用者介面，商務規則寫在使用者介面裡。

這樣做的問題在於：資料庫作為應用程式的中心是不合適的，因為資料庫只負責儲存資料，而不能對資料做出解釋（這是商務規則的任務），而商務規則分散在非中心的位置，零散的表達在使用者介面中。一旦需求改變，商務規則必須隨之改變，而商務規則是分散在各處的，我們就要四處尋找商務規則，進行修改。隨著應用程式規模的擴大，這是一項非常艱難的任務。

為瞭解決複雜的依賴關係，我們建立了業務層。典型的邏輯分層結構就是：展示層->業務層->資料層。

建立業務層的方式可以非常簡單：假如我們的應用程式要進行多項業務，我們分析這些業務的流程，找出這些流程中共同的部分，提取他們作為獨立的過程，這就形成了最簡單的業務層。這樣，不同的介面之間就可以重用商務規則的代碼，從一定程度上解決了依賴關係的不合理性。這是一種基於過程的方法。但是這樣的方法有兩個問題：

第一：他建立在對系統中的各種業務充分瞭解的基礎之上，要正確的分析各個商務程序的細節，否則劃分的流程和提取的共同過程必然有疏漏。但是在實際的開發過程中，我們往往一開始只瞭解業務的整體情況，對於其細節是逐漸瞭解的。並且對於一些隱含的關係，需要在開發的過程中才能認識到。有時候採用的一些具體的開發技術也會影響到某些業務的實現方式，進而對其流程帶來影響。這樣就為過程的分析帶來很大的困難。

第二：基於過程的方法受到需求變化的衝擊比較大。因為這樣的分析方法，在實現的時候是基於業務的過程，而不是業務的目的。當系統中有業務需要變化的時候，會影響到其他具有共同過程的業務，業務之間的依賴是比較嚴重的，對需求變更的適應力差。

如果採用物件導向的方式，將業務進行抽象，概括實現這些業務需要使用的手段（例如需要更新資料表、向連接埠發送指令、保持業務進行的狀態……），為所有的業務制定一個統一的架構，由這個架構決定業務執行的策略（如何限定業務的條件、分哪些步驟、失敗後是重試還是放棄、何時向使用者報告業務執行的進度……），架構不加區別的處理所有的業務。使用者執行一個業務的時候，我們只要相應的建立一個業務對象，將這個對象置於架構內，監視執行的進度。這樣，各個業務的實現就自然的隔離起來，依賴關係比較簡單。同時應付需求變更也比較容易，獨立的業務發生變更，只要修改一個類，如果多個業務的執行方式都要改變，則可以從架構上想辦法。

如果為這個架構添加新的機制，使他不僅能夠執行業務對象，還能夠負責建立和銷毀業務對象，就能夠帶來更強大的功能。業務架構就進而成為一個業務容器。當使用者希望執行一個業務的時候，我們可以要求業務容器建立這個業務對象，業務容器可以交給我們一個業務對象的代理，隱藏真實的對象的位置。實際的執行過程可能是分布式的，容器為我們管理業務對象的事務性，儲存業務執行的進度，必要的時候暫停業務，條件成熟後再重新開始，業務完成以後將對象銷毀……這些我們都不必關心，由容器為我們做。

最佳化應用程式內部的依賴關係是劃分邏輯層次的一個重要目的。層次間的調用機制可以採用逐層調用，也可以跨層調用，都是比較常見的方式。層次間的依賴的方向可以從上到下，也可以從下到上，都是合理的。需要小心的是，兩個層次之間不可以產生互相的依賴，否則會破壞階層。比如有A和B兩個層次，要麼A依賴B，要麼B依賴A，不可以互相依賴。如果必須有層次間互相調用，則必須採用某些方法轉換其中一個方向上的依賴關係（可以採用的方式諸如delegete，interface，訊息，事件等等）。多個層次之間也不應該出現迴圈的依賴關係。

部署層次

部署層次（tier）劃分的目的在於增強應用程式部署的靈活性，更大限度的利用硬體環境資源。應用軟體對環境有多方面的需要，比如資料存放區的模組需要伺服器有較強的穩定性、容錯性、較高的IO效率，交易處理模組則需要運算迅速的處理器和較大的記憶體，而管理終端則需要有較強的表現能力。通常很難有這樣的伺服器滿足多方面的需要，因此我們需要將應用程式分為多個層次，部署在不同的位置。

同時，在某些應用程式中需要訪問一些敏感的資料，這些資料是不允許或者不可能集中到本地的，這都要求程式在部署方面增加靈活性。

從系統效能的角度說，應用程式在部署時劃分合理的層次，可以增加系統的擴充性。當現有的硬體條件不滿足需要的時候，可以通過改變部署方式，提高系統的效能。

比如使用一個伺服器的時候可以滿足100個並發業務，當並發業務達到150的時候，可以通過增加伺服器滿足這個要求。這就需要應用程式使用多層次的結構，缺少必要的層次是不可能進行這樣的擴充的。

再如，我們需要在一個支援20個串連的資料庫上建立一個支援100個用戶端的系統，這時就必須建立獨立於資料庫的串連保持層次。

應用程式的部署層次有一些常用的模式，比如B/S結構，C/S結構，用戶端/應用伺服器/資料服務器結構，都是一些常用的層次劃分模式。具體採用什麼樣的模式要看應用程式的需要，假如應用程式需要頻繁的訪問客戶本地資源，要求較高的效率，或者要求具有強大的離線處理功能，則採用B/S結構就是不合適的，C/S結構是一個比較好的選擇。如果需要在部署配置方面比較簡單，又要面對不同的用戶端環境，那麼B/S結構就是很好的模式。如果需要建立伺服器組來平衡負載，那麼應用伺服器則是必不可少的。

部署層次和邏輯層次有一定的關係，比如說一個程式從邏輯上不分層次，那麼在部署的時候要分為多個層次就很難了。但是這兩種層次並不是必須嚴格一致的，比如說，採用“用戶端/應用伺服器/資料服務器”的部署層次，並不一定意味著用戶端對應著展示層，應用伺服器端對應著業務層，資料服務器就一定是資料層。不能把對應關係絕對化，這兩個角度劃分的層次沒有嚴格的對應關係，他們是為了達到不同的目的而劃分的。

例如：在一些軟體系統中，將商務邏輯以預存程序的形式直接寫在資料庫中。這樣的系統中，業務層與資料服務器是相對應的。這樣的業務層如果處理的好，一樣具有清晰簡潔的邏輯，維護起來也十分方便。但是這樣顯然會在部署上失去靈活性。

現實的問題

很多人在軟體設計中常有這樣的體會：在設計一個軟體體系架構的時候，為了能夠簡化軟體系統的邏輯複雜性，經常採用的手段是將一個大的系統分為若干層次。常用的方法是：分解一個龐大系統的各個功能，將其分別部署在多個組件中，每個組件只完成單一的功能，以減弱組件的複雜程度。組件之間採用一些弱耦合方式進行通訊，比如訊息、TCP串連等方式。

但是實際的開發和維護過程中，卻發現這樣並沒有減輕系統的複雜程度。組件儘管已經從物理上分離，運行在不同的線程、進程、伺服器上，但是組件之間在邏輯上卻有著強烈的耦合關係，組件之間的介面有著時間、空間上的複雜交錯關係，調用者需要依照複雜的邏輯次序，調用被調用者的介面，儲存各次調用之間的狀態，深入到對方的業務過程細節中。系統的結構沒有因為層次而變得簡潔，反而更加的複雜。一個業務的變更會在多個層次中造成影響，變更的代價更加巨大，沒有起到層次模型應有的作用。

造成這個後果的原因在於，設計者混淆了邏輯層次和部署層次之間的區別。如果以減小系統的複雜程度為目的，首要的一點是從邏輯上分開層次，讓各層次對業務的處理處於不同的抽象層級。為業務行為建立合理的抽象層次，而不是簡單的讓各個組件執行業務的某個階段，也不是簡單的讓組件甲執行ABC業務，組件乙執行XYZ業務，這是邏輯層次的關鍵。做到了這一點，才能減小系統的複雜程度。錯誤的邏輯層次劃分，只能使系統變得更加複雜。而盲目的劃分部署層次，則是與初始的目的毫無關係的，也只能增加複雜性。

部署層次劃分的作用並不在於簡化系統邏輯結構，而是增加系統對環境的適應力。

邏輯層次的設計和部署層次的設計在軟體開發中經常是交織在一起進行的，他們互相制約，互相影響，有共同的特徵。但是這兩種層次劃分方式有著本質上的不同，存在著對立的方面，需要開發人員在設計的時候進行協調，這也是需要注意的。