EntityFramework之領域驅動設計實踐介紹

分層架構

在引入例項以前，我們有必要回顧，並進一步瞭解分層架構。“層”是一種體系結構模式^[POSA1]，也是被廣大軟體從業人員用得最為廣泛而且最為靈活的模式之一。記得在CSDN上，時常有朋友問到：“分層是什麼？為什麼要分層？三層架構是不是就是表現層、業務邏輯層和資料訪問層？”

到這裡，你可能會覺得這些朋友的問題很簡單，分層嘛，不就是將具有不同職責的元件分離開來，組成一套層內部高聚合，層與層之間低耦合的軟體系統嗎？不錯！這是分層的目標。但是，我們應該如何分層呢？

領域驅動設計的討論同樣也是建立在層模式的基礎上的，但與傳統的分層架構相比，它更注重領域架構和技術架構的分離。

 

傳統的三層架構

如上文那位朋友提的問題那樣，最簡單的分層方式自然就是“表現層、業務邏輯層和資料訪問層”，我們可以用下圖來表示這個思想：

注意圖中打虛線的“基礎結構層”，從實踐的表現上來看，這部分內容可能就是一些幫助類，比如 SQLHelper之類的，也可能是一些工具類，比如TextUtility之類。這些東西可以被其它各層所訪問。而基於分層的概念，表現層只能跟業務邏輯層打交道，而業務邏輯層在資料持久化方面的操作，則依賴於資料訪問層。表現層對資料訪問層的內容一無所知。

從領域驅動的角度看，這種分層的方式有一定的弊端。首先，為各個層面提供服務的“基礎結構層”的職責比較紊亂，它可以是純粹的技術框架，也可以包含或處理一定的業務邏輯，這樣一來，業務邏輯層與“基礎結構層”之間就會存在依賴關係；其次，這種結構過分地突出了“資料訪問”的地位，把“資料訪問”與 “業務邏輯”放在了等同的地位，這也難怪很多軟體人員一上來就問：“我的資料表該如何設計？”

 

領域驅動設計的分層

領域驅動設計將軟體系統分為四層：基礎結構層、領域層、應用層和表現層。與上述的三層相比，資料訪問層已經不在了，它被移到基礎結構層了。

• 基礎結構層：該層專為其它各層提供技術框架支援。注意，這部分內容不會涉及任何業務知識。眾所周知的資料訪問的內容，也被放在了該層當中，因為資料的讀寫是業務無關的

• 領域層：包含了業務所涉及的領域物件（實體、值物件）、領域服務以及它們之間的關係。這部分內容的具體表現形式就是領域模型（Domain Model）。領域驅動設計提倡富領域模型，即儘量將業務邏輯歸屬到領域物件上，實在無法歸屬的部分則以領域服務的形式進行定義。有關領域物件和領域服務的內容，我會在接下來的案例中進行闡述

• 應用層：該層不包含任何領域邏輯，但它會對任務進行協調，並可以維護應用程式的狀態，因此，它更注重流程性的東西。在某些領域驅動設計的實踐中，也會將其稱為“工作流層”。應用層是領域驅動中最有爭議的一個層次，也會有很多人對其職責感到模糊不清。比如，有些國外的開發人員會覺得，既然不包含領域邏輯，那又如何協調工作任務呢？我會在《應用層與實體事件》章節對這些問題進行探討

• 表現層：這個好理解，跟三層裡的表現層意思差不多，但請注意，“Web服務”雖然是服務，但它是表現層的東西

從上圖還可以看到，表現層與應用層之間是透過資料傳輸物件（DTO）進行互動的，資料傳輸物件是沒有行為的POCO物件，它的目的只是為了對領域物件進行資料封裝，實現層與層之間的資料傳遞。為何不能直接將領域物件用於資料傳遞？因為領域物件更注重領域，而DTO更注重資料。不僅如此，由於“富領域模型”的特點，這樣做會直接將領域物件的行為暴露給表現層。