軟體的邏輯層次

基本層次

軟體的邏輯結構可以劃分為下面四個基本層次：

從下往上依次是：

1：基礎設施層——這個層次是純技術層次，解決的是系統的物理問題，比如database gateway、網路通訊、對象容器……這個部分與業務需求關係不大，是系統的物理條件。

2：business對象——在這個層次上，業務要素出現了，業務領域中的概念在這裡實現。比如一個航運公司的系統，這裡就應該有航線、航班、座位、乘客、登機證……這些對象應該擁有與實際業務領域相符的屬性、方法。

3：business流程——這個流程不是指程式解決問題的流程，而是使用者的商務工作的流程。他體現的是端到端的商務程序。比如：檢票員為旅客辦理登機證。business流程的輸入參數是business對象，輸出參數是business對象，產生的異常也是business對象。business對象在這裡組合、串接，實現商務程序的自動化。這個層次是在直接實現使用者的需求。

4：UI和介面——這個層面調用business流程，將執行的結果交給軟體的使用者，或者別的系統。

這種邏輯層次劃分是最基本的情況，各種複雜的層次都是這種方式的一種擴充。比如下面這樣的形式：

在基礎設施層和business對象之間，加入了一個DAO層。DAO層一方面負責資料的儲存，體現了資料的儲存方式，另一方面體現了業務對象的屬性。這樣就使business對象只需要負責純粹的商務邏輯，不用關心物理問題。簡單的說，業務對象裡面不需要寫SQL語句了。

business對象和business過程之間，加入了Service層。business對象也是具有行為的，但是這樣的行為是比較細微的，需要調用者在多次調用之間保持必要的狀態，需要用Service層來做一個封裝，更明確的表達業務含義。

單元測試

單元測試需要關心一個問題：層次之間的依賴關係。如果要測試某一個層次上的對象，必須同時建立他所依賴的每一個對象。層次之間的依賴越簡單，測試越容易。

邏輯層次之間原則上是由上至下的依賴關係，同一層次內部的對象可以互相依賴。跨越層次的調用也是允許的，比如在UI Process中調用Business對象。UI層和UI Process層之間存在著互相的依賴。開發中我們最希望測試的是這三個層次：business過程、service、business對象。我們只要對下層對象建立stub對象，就可以對這三個層次上的對象進行測試。

對這三個層次的測試結果不僅保證了程式的運行時正確性，也是對程式的商務程序進行測試。在開發過程中和維護過程中，某個商務程序發生了變化，可以用單元測試保證其他流程不會受到危害。這樣的構架可以保證反覆式開發法過程。

和物理層次的結合

上面說的都是系統的邏輯層次。在系統中還存在著另一個層次——物理層次。邏輯層次的目的是簡化程式的邏輯複雜度，便於開發和維護；物理層次的實現需要考慮實際的物理分布情況，合理的安排每個物理節點的任務，最大限度提高系統的效能。邏輯層次和物理層次的劃分依據和劃分目的都是不一樣的，他們之間存在著聯絡，但也不是絕對的。

邏輯層次和物理層次的結合有兩種方式：

1、在基礎設施層解決掉物理分布的問題，建立一個分布式的對象容器，把business對象和service放到容器中。這樣，business對象和service就不必處理複雜的物理分布問題，business過程也不必關心他所調用的對象是在什麼位置建立的。這樣的方式最大限度的減少了物理結構對程式邏輯結構的影響，增加了物理分布的靈活性。但是在大部分情況下，對系統的效率都是有危害的。

2、在business對象內部處理物理分布的問題，或者制定一個技術無關的介面來體現business對象，在各物理節點編寫各自的實現。這樣物理層次和邏輯層次是攪在一起的，使系統的邏輯結構顯得混亂，但是可以達到較高的運行效率。