基于領域驅動設計的軟件開發方法和實例分析

陳 亮

（廣州鐵路（集團）公司科學技術研究所，廣州510100）

當今，Web 應用的重要性已經得到了廣泛認同，越來越多的應用系統都被構建在Web 之上。基于Web 的多層架構體系（如ASP.NET）已經成為解決企業級應用的主要途徑。然而，傳統的數據庫驅動設計方法（以數據庫建模為核心的軟件開發方法）在基于Web 多層架構的企業級應用系統開發中存在諸多不足。本文在分析了數據庫驅動設計方法存在不足的基礎上，引入領域驅動設計（DDD）方法，并研究了這種設計方法在動態表單系統開發中的應用。

1 數據庫驅動設計方法存在的問題

1.1 不能有效地反映需求

面向對象的思維方式符合人類的自然思維，因此采用OOA（面向對象分析方法）進行需求分析可以使得軟件的需求（問題域）和實現（解決域）在形式上是一致的，很便于理解，因此采用面向對象數據庫是首選。然而，對于OODB（面向對象數據庫）來說，從技術上還不夠成熟，商品化的OODBMS 尚不普及，目前主流的DBMS（Microsoft SQL Server，Oracle，DB2 等）都是關系型的。

傳統的以數據庫建模為核心的軟件開發是基于關系型數據庫的。這樣必將導致需求分析(問題域)與系統實現（解決域）在形式上不一致，影響設計人員的設計思路，甚至使整個系統的設計偏離用戶需求。現代的軟件系統構架應該是問題域建模和模式，也就是說，在做系統設計的時候，首先要搞清楚對象：當前的問題是什么？解決這個問題需要什么樣的邏輯和業務流程？選擇什么樣的模式或軟件框架才可以解決這樣的問題，并使得軟件系統具有鮮活的生命力？在現代的軟件構架模式中，數據庫的重要性已經顯得不太明顯了，它只不過是一種數據持久化的機制，與問題域建模一點關系都沒有。

1.2 導致過程化編程

現在，面向對象程序設計已被人們廣為接受，傳統的面向過程程序設計方法在系統的可維護性、可擴展性方面存在嚴重瓶頸。而以數據庫建模為核心的軟件開發方法容易導致過程化程序設計。因為數據庫建模，首先是根據需求確定數據庫結構，然后程序員編寫過程化的SQL語句、存儲過程。這些過程化元素將導致業務邏輯無法用完全面向對象（OO）的思想來實現，從而導致開發出來的系統可維護性和可擴展性低下。

軟件系統的設計要求能夠考慮到由于問題域矛盾的變化而帶來的功能性甚至結構性的變化。在首先確定數據庫設計的軟件設計中，在更改業務邏輯層的處理過程之前還需要首先考慮數據庫設計的變更。表面上看，軟件3層體系結構體現得很完善，各層分工很明確，其實這種做法仍然沒有降低業務邏輯層和數據持久層的耦合度。

1.3 運行性能影響

圍繞數據庫分析設計容易導致軟件運行時負載集中在數據庫端，系統性能難于擴展（走上集中式、昂貴的、高風險的大型機模式），閑置了中間件（如.Net服務器）分布式集群處理能力，就是使用了集群，也分擔不了負載。

軟件系統設計應該把重點放在問題域建模以及模式和框架的選擇上。問題域建模可以解決實際的業務邏輯問題，模式和框架則是軟件生命力的重要保障，數據在問題域建模中流動，數據庫是數據流動的終點。從理論上來講，數據完全可以持久化到文件，或者只要能夠保證足夠的內存以及服務器永不停機，數據完全可以高效地保存在內存中，這樣也就沒有使用數據庫的必要了。當然也不是數據設計不重要。應該把系統設計重點放在問題域上，而不是數據庫上。數據庫仍然是現在主流的數據持久化機制，但只負責數據持久化，它并不能決定業務流程。事實上，現在的Hibernate和NHibernate就是一個數據持久化框架，它能夠使得軟件設計和開發人員擺脫數據持久層的實現細節，將業務邏輯層和數據持久層的耦合度降到最低。

2 軟件的領域和模型

軟件總會與其用戶的活動和興趣相關，用戶在使用軟件中主要的環境稱為軟件的領域。軟件開發的目的就是通過計算機解決某一領域的實際問題。這樣的定義已經將立足點置于領域層面了：需要關注的是領域本身，而不是其它的技術細節。模型是知識的一種有選擇的簡化和有意識的組織形式，一個合適的模型可以有效地表達軟件領域，目前流行的軟件模型表示方法為UML。

2.1 領域驅動設計與模型驅動設計

領域驅動設計應該是建立在模型驅動設計的基礎上，但兩者有所不同，主要表現在領域模型不僅僅是模型，還包括與模型相關的用來完成與業務邏輯相關的其他元素，比如服務等。此外領域模型還具有獨有的特性：完成性約束，相互關聯和訪問機制。

2.2 領域的組成

通常將領域中的組成角色分為以下5種：實體（Entity）、值對象（Value Object）、工廠（Factory）、倉儲（Repository）、服務（Service）。

（1）實體：實體是在做開發的時候經常遇見的領域對象。實體是一種領域對象，在特定的上下文（Context）中，需要關心的不僅僅是“它是什么”，要更深入地知道“它是哪個”，因此，實體需要有自己的唯一標識符。以標識作為基本定義的對象稱為“實體”。

（2）值對象：如果一個對象代表了領域的某種描述特征，并沒有概念性的標識，那么它就是值對象。

（3）工廠：定義創建實體的方法。它的職責，就是創建對象。既然是創建對象，那我們為什么不直接實例化呢？簡單的情況是可以的，往往會給工廠帶來巨大的好處，簡單地說就是屏蔽了創建對象的復雜性。

（4）倉儲：倉儲的概念和一些人常說的數據訪問對象（DAO）有些類似，但是并不等同，二者一個很大的不同是倉儲有“根”的概念，而數據訪問對象往往是按照數據庫的表來劃分的。

（5）服務：服務不屬于實體也不屬于值對象，代表的一些重要領域操作，是一些本質的行為和動作，被執行的操作涉及到領域中的其他的對象，除了操作外，服務是無狀態的。當領域中的一個重要的過程或者變化不屬于一個實體或者值對象的自然職責時，向模型中增加一個操作，作為一個單獨的接口將其申明一個服務。

3 領域驅動設計的系統分層架構

Web系統普遍采用MVC的分層架構，在基于領域驅動設計的系統中，層次進一步細化，領域模型得到隔離，見圖1。

圖1 系統分層架構圖

（1）用戶界面層（表現層）：這一層封裝了服務于訪問系統的客戶端所需的所有表現邏輯，攔截了客戶端的請求，提供了單一的登陸入口，構造了會話的管理。控制了對業務服務的訪問，構造了響應，并且把這些響應傳遞給客戶端。

（2）應用層：定義了系統要完成的工作，不負責業務邏輯的實現，而是指導下層的領域層來進行業務邏輯的實現工作。

（3）領域層（模型層）：負責系統業務邏輯的實現工作，這一層是業務軟件的核心。

（4）基礎結構層：為上層提供通用的技術能力：應用的消息發送、領域持久化，為用戶界面繪制窗口等。該層還負責與外部資源、外部系統（比如數據存儲和遺留應用系統）通信。

4 實例分析

動態表單系統是設計人員根據實際需求，設計好表單格式，然后用戶根據自己的實際情況填寫表格所要求的內容。本文以動態表單的分析作為實例，基于DDD開發模式為指導，通過和領域專家的多次交流，迭代得到一個動態表單的領域模型，如圖2。

圖2 動態表單領域模型

4.1 精簡關聯關系

用戶（Designer）和動態表單（Dynamic-TableInfo）是一個多對多的關系，為了減少復雜性，指定一個導向，指定這種關聯是從Dynamic-TableInfo到Designer的，也就是說，所關心的是DynamicTableInfo是由哪個Designer來操作，這樣子多對多的關系就可以變成一對多的關系，再通過Role限定Designer的不同身份，進一步將一對多的關聯精簡成一對一的關聯。

4.2 區分實體和值對象

TableModel不具有連續性標識，只是描述DynamicTableInfo的一個值對象；Designer的標識（DesignerID）必須在整個動態表單系統中進行跟蹤，因此Designer是實體；DynamicTableInfo是動態表單的必備數據，必須有連續的標識，因此是實體，DynamicTableOutPut和DynamicTable-CKInfo是動態表單的實際輸出數據和審核數據，具有連續的標識，也是實體。

4.3 服務

DealHandler不是實體也不是值對象，這個只是負責為用戶提供處理DynamicTableInfo的服務。因此它是服務。

4.4 領域對象的管理

4.4.1 聚合邊界的設置

出于數據庫多用戶訪問時的安全問題，需要為一簇相關聯的對象設置邊界，以控制用戶的訪問方式。DynamicTableOutPut，DynamicTable-CKInfo，DynamicTableInput，都有自己的標識，并且有時需要單獨對其進行跟蹤。因此其是自己的聚合根。TableModel，Designer，Dynamic-TableInfo 應該放入一個聚合體內，因為無需單獨對TableModel，Designer進行跟蹤。Dynamic-TableInfo是這個聚合體的聚合根。

4.4.2 選擇倉儲

只有作為聚合根的實體才能夠擁有倉儲。本系統中聚合根有DynamicTableInfo (聚合體的聚合根)、DynamicTableOutPut，DynamicTable-CKInfo，DynamicTableInput，相應的倉儲為DynamicTableInfo Repository、DynamicTableOutPut Repository、DynamicTableCKInfo Repository、DynamicTableInput Repository。倉儲在實現階段可以采用DAO 模式，圖3展示了部分模型的聚合邊界設置和聚合根的倉儲定義。

圖3 部分模型聚合根的倉儲定義

4.4.3 對象創建

基于動態表單領域對象的復雜性，為此采用工廠模式來進行對象的創建，將復雜的創建任務從領域對象中分離到工廠對象中。根據不同的情況可采用相應的設計模式實現工廠模式：工廠方法，抽象工廠和構造器。如圖4為DynamicTableInfo對象的工廠構造過程。

4.5 編碼實現

根據領域模型編碼實現系統功能。

4.6 重構

圖4 對象的工廠構造過程

對軟件進行重新設計而不改變軟件的功能，重構不要求預先做出各種詳細設計，而是對代碼進行一系列小的獨立的修改，每次修改都保持功能不變，使得設計更加靈活易懂。模型重構是基于對領域的理解來執行的，通常包含一系列的微重構，逐漸產生一個更加合理的模型。每次獲得新的領域知識或者深入的理解之后，都應該將模型重構到更深的層次。

5 領域驅動設計的優點

在利用領域驅動設計（DDD）方法進行系統建模以及后續的開發過程中，系統帶來了許多優點。

（1）基于模型驅動開發（MDD）思想的DDD采用面向對象的思維方式，符合人類自然思維。

（2）基于DDD方法構建的上述動態表單模型，能夠很自然的引導程序開發人員采用面向對象思路實現系統，從而確保開發出的動態表單系統具有很好的可維護性和可擴展性。

（3）采用DDD 開發出的系統能夠充分地利用中間件（如.Net服務器）分布式集群處理的能力，減輕了數據庫端的負載過重問題。

6 結束語

通過對軟件領域的分析，得到一個領域模型，在領域模型的基礎上進行軟件的設計與實現工作，通過重構的方法進行領域模型的精化工作。

[1] 甄鐳. .Net與設計模式[M] . 北京：電子工業出版社， 2006.

[2] Eric Evans. 領域驅動設計[M] . 陳大峰，張澤鑫. 北京：清華大學出版社，2006.

[3] 湯晨，吳朝暉. 一個利用模型驅動體系結構技術的分布式系統實現[J] .計算機工程與應用，2003，（33）：133-135.

[4] WhiteC. xSLT從入門到精通[M] . 王健，王軍. 北京：機械出版社，2003.