從三層架構邁向領域驅動設計

嚴格分層架構模式的特點是上層只能訪問相鄰的下層，其他層次間的呼叫都不允許。三層架構就是一種嚴格分層模式，它把職責劃分為介面展示、業務邏輯、資料訪問三層，還有乙個業務實體，前面三層都要依賴它，所以它並不構成乙個層。

三層架構的特點是一種面向過程的程式設計思想，特點如下：

a. 業務實體類中基本上只有屬性沒有方法。

b. 業務邏輯層的類基本上只有方法沒有屬性。

c. 將資料表結構對映為業務實體類是乙個慣用做法，以至於有人將其稱之為「傳統」。這樣的好處是只需要理解一套模型，能夠通過自動化工具從資料表直接生成業務實體，還能夠自然而然的通過自動化機制儲存與檢索業務實體。但對於複雜點的業務，這樣做就是絕大部分問題的根源。

d. 當業務膨脹起來，需要劃分模組的時候，我們有個常用的變形：提取乙個服務層出來，用來組合模組間的互動，還為業務邏輯層提供了乙個防腐層，可以把記錄日誌、驗證許可權、處理異常等職責分配給服務層。

由於採用了嚴格分層模式，使用者介面層是絕對不能跨過業務邏輯層呼叫資料訪問層的，同理服務層也是不能呼叫資料訪問層。但是圖2都有四層了。

其實三層架構還有個更準確的名字----分層貧血領域模型架構，前面名字中的領域模型指的是業務實體，貧血意思業務實體中沒有或很少方法。

三層架構的最大問題在於：實際應用中人們喜歡把記憶體模型和資料庫模型保持一致。三層架構的大部分問題都是從這裡衍生出來的。

資料庫模型的粒度如果很小，那麼大量的表連線很快就會讓資料庫跑不動了。

如果資料庫模型的粒度如果很大（這是大部分專案的選擇），**的質量（重用性、穩定性、擴充套件性）就很差。由於沒有從業務的角度去仔細定義每乙個物件，每個人會根據自己的需要建立各種querymodel或viewmodel，慢慢地類會多到想哭。

還有一些三層開發人員最終患上了資料庫痴迷症，他堅信程式就應該做個搬運工，其他的事情都應該交給資料庫來完成，業務邏輯也應該寫進儲存過程裡面去。

優化三層結構&重構到物件導向的設計

由於目前的服務層職責是非常輕的，甚至有很多空殼的呼叫，所以平衡一下職責，把呼叫資料訪問層的職責從業務邏輯層提公升到服務層，需要的資料通過引數傳遞給業務邏輯層。這樣，對於那些簡單到無業務邏輯的crud就不需要去訪問業務層了，直接呼叫資料訪問層。

結構如圖3，我們看到業務邏輯與資料訪問層已經沒有依賴關係了。

然後我們就可以把業務邏輯與業務實體移到一塊。

然後把屬於業務實體的邏輯遷移到實體類中。

圖4基本上就是圖3的各個層換了名字，並且ui可以訪問基礎設施層。而圖4與圖5的區別在於，圖4是基礎設施依賴領域層，圖5是領域層依賴基礎設施層。

原版----負責向使用者展現資訊以及解釋使用者命令。

補充---- mvc中v和c都屬於ui層，v展現資訊，c解析使用者命令。ui像地圖一樣把各個控制器關聯了起來。

原版----很薄的一層，用來協調應用的活動。它不包含業務邏輯。它不保留業務物件的狀態，但它保有應用任務的進度狀態。

補充----協調應用的活動這句話太抽象了，我充實一下它：從資料訪問中獲取領域物件，呼叫領域物件的方法完成任務，然後再呼叫資料訪問**把領域物件的改變持久化。事務、許可權檢查、記錄日誌、處理異常的職責也歸它管。這點和前面三層的服務層的職責其實是一樣的。

原版----本層包含關於領域的資訊。這是業務軟體的核心所在。在這裡保留業務物件的狀態，對業務物件和它們狀態的持久化被委託給了基礎設施層。

補充----業務物件的持久化工作我們已經提公升到應用層了，一般情況下，這層最好不要涉及資源庫的呼叫，但是並不絕對。資源庫的抽象要麼在領域層中，要麼提公升到了「應用程式框架」，領域層是不會依賴基礎設施的。

原版----本層作為其他層的支撐庫存在。它提供了層間的通訊，實現對業務物件的持久化，包含對使用者介面層的支撐庫等作用。

a. ui層技術基本一樣，一些比較智慧型的繫結可能無法進行了。

b. 服務層基本一樣。

d. 業務實體+業務邏輯 = 領域層

e. 如果三層架構不採用業務實體與資料表一致的做法，這層也是一樣。由於記憶體結構與資料表結構之間存在阻抗失配，訪問領域物件沒那麼簡單。

參考資料

《領域驅動設計精簡版》