基于領域驅(qū)動設計的軟件開發(fā)方法和實例分析

陳 亮

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

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

1 數(shù)據(jù)庫驅(qū)動設計方法存在的問題

1.1 不能有效地反映需求

面向?qū)ο蟮乃季S方式符合人類的自然思維，因此采用OOA（面向?qū)ο蠓治龇椒ǎ┻M行需求分析可以使得軟件的需求（問題域）和實現(xiàn)（解決域）在形式上是一致的，很便于理解，因此采用面向?qū)ο髷?shù)據(jù)庫是首選。然而，對于OODB（面向?qū)ο髷?shù)據(jù)庫）來說，從技術上還不夠成熟，商品化的OODBMS 尚不普及，目前主流的DBMS（Microsoft SQL Server，Oracle，DB2 等）都是關系型的。

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

1.2 導致過程化編程

現(xiàn)在，面向?qū)ο蟪绦蛟O計已被人們廣為接受，傳統(tǒng)的面向過程程序設計方法在系統(tǒng)的可維護性、可擴展性方面存在嚴重瓶頸。而以數(shù)據(jù)庫建模為核心的軟件開發(fā)方法容易導致過程化程序設計。因為數(shù)據(jù)庫建模，首先是根據(jù)需求確定數(shù)據(jù)庫結(jié)構，然后程序員編寫過程化的SQL語句、存儲過程。這些過程化元素將導致業(yè)務邏輯無法用完全面向?qū)ο螅∣O）的思想來實現(xiàn)，從而導致開發(fā)出來的系統(tǒng)可維護性和可擴展性低下。

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

1.3 運行性能影響

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

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

2 軟件的領域和模型

軟件總會與其用戶的活動和興趣相關，用戶在使用軟件中主要的環(huán)境稱為軟件的領域。軟件開發(fā)的目的就是通過計算機解決某一領域的實際問題。這樣的定義已經(jīng)將立足點置于領域?qū)用媪耍盒枰P注的是領域本身，而不是其它的技術細節(jié)。模型是知識的一種有選擇的簡化和有意識的組織形式，一個合適的模型可以有效地表達軟件領域，目前流行的軟件模型表示方法為UML。

2.1 領域驅(qū)動設計與模型驅(qū)動設計

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

2.2 領域的組成

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

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

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

（3）工廠：定義創(chuàng)建實體的方法。它的職責，就是創(chuàng)建對象。既然是創(chuàng)建對象，那我們?yōu)槭裁床恢苯訉嵗?？簡單的情況是可以的，往往會給工廠帶來巨大的好處，簡單地說就是屏蔽了創(chuàng)建對象的復雜性。

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

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

3 領域驅(qū)動設計的系統(tǒng)分層架構

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

圖1 系統(tǒng)分層架構圖

（1）用戶界面層（表現(xiàn)層）：這一層封裝了服務于訪問系統(tǒng)的客戶端所需的所有表現(xiàn)邏輯，攔截了客戶端的請求，提供了單一的登陸入口，構造了會話的管理?？刂屏藢I(yè)務服務的訪問，構造了響應，并且把這些響應傳遞給客戶端。

（2）應用層：定義了系統(tǒng)要完成的工作，不負責業(yè)務邏輯的實現(xiàn)，而是指導下層的領域?qū)觼磉M行業(yè)務邏輯的實現(xiàn)工作。

（3）領域?qū)樱Ｐ蛯樱贺撠熛到y(tǒng)業(yè)務邏輯的實現(xiàn)工作，這一層是業(yè)務軟件的核心。

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

4 實例分析

動態(tài)表單系統(tǒng)是設計人員根據(jù)實際需求，設計好表單格式，然后用戶根據(jù)自己的實際情況填寫表格所要求的內(nèi)容。本文以動態(tài)表單的分析作為實例，基于DDD開發(fā)模式為指導，通過和領域?qū)＜业亩啻谓涣?，迭代得到一個動態(tài)表單的領域模型，如圖2。

圖2 動態(tài)表單領域模型

4.1 精簡關聯(lián)關系

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

4.2 區(qū)分實體和值對象

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

4.3 服務

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

4.4 領域?qū)ο蟮墓芾?/h3>

4.4.1 聚合邊界的設置

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

4.4.2 選擇倉儲

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

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

4.4.3 對象創(chuàng)建

基于動態(tài)表單領域?qū)ο蟮膹碗s性，為此采用工廠模式來進行對象的創(chuàng)建，將復雜的創(chuàng)建任務從領域?qū)ο笾蟹蛛x到工廠對象中。根據(jù)不同的情況可采用相應的設計模式實現(xiàn)工廠模式：工廠方法，抽象工廠和構造器。如圖4為DynamicTableInfo對象的工廠構造過程。

4.5 編碼實現(xiàn)

根據(jù)領域模型編碼實現(xiàn)系統(tǒng)功能。

4.6 重構

圖4 對象的工廠構造過程

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

5 領域驅(qū)動設計的優(yōu)點

在利用領域驅(qū)動設計（DDD）方法進行系統(tǒng)建模以及后續(xù)的開發(fā)過程中，系統(tǒng)帶來了許多優(yōu)點。

（1）基于模型驅(qū)動開發(fā)（MDD）思想的DDD采用面向?qū)ο蟮乃季S方式，符合人類自然思維。

（2）基于DDD方法構建的上述動態(tài)表單模型，能夠很自然的引導程序開發(fā)人員采用面向?qū)ο笏悸穼崿F(xiàn)系統(tǒng)，從而確保開發(fā)出的動態(tài)表單系統(tǒng)具有很好的可維護性和可擴展性。

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

6 結(jié)束語

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

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

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

[3] 湯晨，吳朝暉. 一個利用模型驅(qū)動體系結(jié)構技術的分布式系統(tǒng)實現(xiàn)[J] .計算機工程與應用，2003，（33）：133-135.

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