最近在研究DDD頗有收獲，所以整理出來(lái)跟大家分享，共同進(jìn)步！

我們?cè)谠O(shè)計(jì)業(yè)務(wù)系統(tǒng)的時(shí)候都會(huì)存在一個(gè)非常棘手而又無(wú)法回避的問(wèn)題“業(yè)務(wù)擴(kuò)展性”、“業(yè)務(wù)靈活性、”面向?qū)ο蠡?ldquo;，盡管我們熟練掌握設(shè)計(jì)思想、設(shè)計(jì)模式、設(shè)計(jì)原則等等關(guān)于如何設(shè)計(jì)靈活性的系統(tǒng)設(shè)計(jì)理論，但是我們似乎都沒(méi)有將它們運(yùn)用到真正業(yè)務(wù)系統(tǒng)設(shè)計(jì)、開(kāi)發(fā)當(dāng)中去，為什么？這樣的疑問(wèn)如果對(duì)有心想設(shè)計(jì)好系統(tǒng)的朋友來(lái)說(shuō)肯定是很早就出現(xiàn)過(guò)，只是無(wú)法解決，因?yàn)槲覀兡壳笆褂玫脑O(shè)計(jì)方法是與面向?qū)ο笤O(shè)計(jì)背道而馳的。

漫長(zhǎng)的數(shù)據(jù)庫(kù)驅(qū)動(dòng)開(kāi)發(fā)歷史，導(dǎo)致我們根本無(wú)法脫離這個(gè)環(huán)境進(jìn)行學(xué)習(xí)和實(shí)戰(zhàn)。從教科書再到真正的企業(yè)項(xiàng)目開(kāi)發(fā)都是先設(shè)計(jì)數(shù)據(jù)庫(kù)然后進(jìn)行邏輯的編寫，大部分的業(yè)務(wù)邏輯都是存在于UI和數(shù)據(jù)庫(kù)【存儲(chǔ)過(guò)程、自定義函數(shù)】中，所謂的三層架構(gòu)中的BLL層其實(shí)是形同虛設(shè)，根本沒(méi)有起到它應(yīng)有的作用。

當(dāng)然我們不是大師，我們只是普通的程序員，希望有一種方法論能引導(dǎo)我們進(jìn)行真確的系統(tǒng)設(shè)計(jì)。在未接觸DDD之前，我也一樣有著同樣的困擾，我們編寫很多的開(kāi)發(fā)框架、組件、插件、服務(wù)等等太多太多類似能提高開(kāi)發(fā)效率的功能，夢(mèng)想著自己的系統(tǒng)能想真正如書上所說(shuō)的搭積木一樣搭建自己的系統(tǒng)，我們捫心問(wèn)自己真的可以做到嗎？我嘆息，很難；

我一直感覺(jué)復(fù)雜的系統(tǒng)設(shè)計(jì)對(duì)我來(lái)說(shuō)真的沒(méi)有辦法應(yīng)付，只能憑借細(xì)心和對(duì)業(yè)務(wù)的熟悉程度，沒(méi)有正確的理論引導(dǎo)，那些所謂的大師們的設(shè)計(jì)思想的書真的對(duì)我?guī)椭淮螅戳瞬恢廊绾芜M(jìn)行運(yùn)用。時(shí)至今日我終于可以感覺(jué)到那種神秘的設(shè)計(jì)確實(shí)可以帶領(lǐng)我們穿越復(fù)發(fā)的系統(tǒng)設(shè)計(jì)。當(dāng)然這條路對(duì)剛開(kāi)始接觸DDD的朋友來(lái)說(shuō)會(huì)存在很多問(wèn)題，恰巧在下有幸接觸DDD有點(diǎn)心得，也通過(guò)分析了一個(gè)小的系統(tǒng)進(jìn)行DDD的開(kāi)發(fā)工作，所以在這里把自己最近研究的心得和疑惑跟同行們分享，如有不對(duì)的地方請(qǐng)多指點(diǎn)。

【1.1】疑問(wèn)

在任何一項(xiàng)新技術(shù)被采納之前必須要解決幾個(gè)關(guān)鍵的問(wèn)題，這也是我們程序員考慮使用一項(xiàng)新技術(shù)的必須過(guò)程，它的出現(xiàn)能解決哪些問(wèn)題和將會(huì)帶來(lái)哪些問(wèn)題。DDD固然很好，但是要想把它運(yùn)用到自己的項(xiàng)目當(dāng)中去，是需要很多時(shí)間和精力來(lái)分析它的實(shí)施過(guò)程和對(duì)項(xiàng)目團(tuán)隊(duì)的要求。當(dāng)然人為的因素和外在的環(huán)境問(wèn)題我們這里不考慮，畢竟那些是我們無(wú)法改變的事情，這里只討論和我們密切相關(guān)的問(wèn)題。

【1.1.1】UML何用

做程序開(kāi)發(fā)的我們都知道UML是干什么的，簡(jiǎn)單的講它屬于一種標(biāo)準(zhǔn)的系統(tǒng)建模語(yǔ)言，便于我們對(duì)系統(tǒng)進(jìn)行分析和團(tuán)隊(duì)之間的合作。既然是語(yǔ)言它的主要作用是溝通，技術(shù)人員和分析人間的橋梁。但是到目前為止我沒(méi)有發(fā)現(xiàn)它真正幫助過(guò)我進(jìn)行系統(tǒng)分析和設(shè)計(jì)，上面已經(jīng)提過(guò)其實(shí)是兩種開(kāi)發(fā)方法論恰恰相反，所以導(dǎo)致根本無(wú)法集成，就拿UML中的類圖來(lái)講，我們都是先設(shè)計(jì)數(shù)據(jù)庫(kù)然后進(jìn)行開(kāi)發(fā)何來(lái)的對(duì)象？直接是表驅(qū)動(dòng)，通過(guò)一些快速的代碼生成器進(jìn)行界面和一些通用的單表的CDUS代碼的生成，程序中根本沒(méi)有對(duì)象的概念，業(yè)務(wù)邏輯遍布UI層[圖1.1]。UML畫的類圖無(wú)法在程序中表現(xiàn)出來(lái)，所以它無(wú)法在絕大部分的企業(yè)中普及。

1.1圖

上圖假設(shè)是一個(gè)簡(jiǎn)單的模擬B2C的基本功能，通過(guò)它我們能簡(jiǎn)單的了解到我們的系統(tǒng)開(kāi)發(fā)的問(wèn)題所在。

以上圖中的系統(tǒng)結(jié)構(gòu)，我們很難知道系統(tǒng)的具體業(yè)務(wù)邏輯，更別說(shuō)對(duì)系統(tǒng)的擴(kuò)展性能有保障。這樣的結(jié)構(gòu)在開(kāi)發(fā)初期沒(méi)有什么問(wèn)題，但是在后期的維護(hù)工作中將是費(fèi)事費(fèi)力的，最后的項(xiàng)目代碼無(wú)法進(jìn)行的很好的閱讀，也就無(wú)法很好的進(jìn)行穩(wěn)定性維護(hù)。特別是業(yè)務(wù)系統(tǒng)，它的需求會(huì)變的很多甚至很變態(tài)，如果按照這種方式進(jìn)行維護(hù)，那么界面上的代碼會(huì)越來(lái)越多，而B(niǎo)LL、DAL中的重復(fù)性的功能方法也會(huì)急劇變多或者是服務(wù)層的相同功能不同方法參數(shù)的代碼會(huì)越來(lái)越多。其實(shí)到最后也就談不上什么藝術(shù)了，更別說(shuō)項(xiàng)目進(jìn)行產(chǎn)品化后上市。

那么UML真的起不到作用嗎？或者說(shuō)我們真的與UML無(wú)緣？當(dāng)然不是，而是我們沒(méi)有使用相關(guān)的軟件設(shè)計(jì)、開(kāi)發(fā)方法論而已。按照DDD的思想，我們是業(yè)務(wù)驅(qū)動(dòng)開(kāi)發(fā)，先進(jìn)行領(lǐng)域模型的創(chuàng)建，然后才是數(shù)據(jù)庫(kù)的設(shè)計(jì)。其實(shí)只有按照DDD的開(kāi)發(fā)理論來(lái)才能最大的保證系統(tǒng)的擴(kuò)展性和業(yè)務(wù)整潔性，才能保證項(xiàng)目的良性循環(huán)。

#p#

【1.1.2】領(lǐng)域建模

“領(lǐng)域建模”很抽象也很藝術(shù)的一個(gè)詞，它是軟件設(shè)計(jì)藝術(shù)中的一個(gè)境界。

我們常常接觸面向?qū)ο缶幊?、面向?qū)ο笤O(shè)計(jì)的書籍或者話題，大家都對(duì)它有獨(dú)特的見(jiàn)解，但是我們始終沒(méi)有將它用作真正的系統(tǒng)性開(kāi)發(fā)中去。但是在編寫框架的時(shí)候我們都能得心應(yīng)手的進(jìn)行面向?qū)ο笤O(shè)計(jì)，為了保證框架的靈活性乃至最大的擴(kuò)展性就要進(jìn)行最細(xì)粒度的分解、抽象、提取，這些在非數(shù)據(jù)庫(kù)系統(tǒng)開(kāi)發(fā)中都沒(méi)有問(wèn)題。然而最大的問(wèn)題出在對(duì)象需要與數(shù)據(jù)庫(kù)結(jié)合，對(duì)象的生命周期持久化在數(shù)據(jù)庫(kù)中，生也數(shù)據(jù)庫(kù)死也數(shù)據(jù)庫(kù)。所以這里的問(wèn)題就是如何在面向?qū)ο笤O(shè)計(jì)與關(guān)系型數(shù)據(jù)庫(kù)設(shè)計(jì)之間平滑的過(guò)度持久化。這是領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)的最大的問(wèn)題，也是很多面向DDD框架的開(kāi)發(fā)重點(diǎn)。

在上圖中我們目睹了以數(shù)據(jù)庫(kù)驅(qū)動(dòng)后系統(tǒng)的大致結(jié)構(gòu)，假設(shè)我們需要保證功能模塊的最大的擴(kuò)展性我們?cè)诰帉憯?shù)據(jù)庫(kù)驅(qū)動(dòng)代碼的時(shí)候，很難抽象出復(fù)雜的變化點(diǎn)，因?yàn)槎际秦氀偷臉I(yè)務(wù)模型或者說(shuō)根本不知道變化點(diǎn)在什么地方。而且并不是普通的開(kāi)發(fā)人員能發(fā)掘到的，當(dāng)然數(shù)據(jù)庫(kù)驅(qū)動(dòng)開(kāi)發(fā)也一樣可以進(jìn)行靈活設(shè)計(jì)、開(kāi)發(fā)，但是這樣畢竟對(duì)開(kāi)發(fā)人員要求很高，他需要具備很強(qiáng)的面向?qū)ο笤O(shè)計(jì)能力，在不污染現(xiàn)有的代碼的情況下進(jìn)行擴(kuò)展性重構(gòu)。至少我的經(jīng)驗(yàn)告訴我很難，而且在需求階段并沒(méi)有一個(gè)完整的大局觀，很容易造成頭重腳輕。對(duì)后期的系統(tǒng)開(kāi)發(fā)進(jìn)度也很難控制，因?yàn)闊o(wú)法確定每個(gè)功能模塊到底存在哪些接口。

所以我們還是朝著光明的道路前進(jìn)，掌握DDD進(jìn)行系統(tǒng)設(shè)計(jì)開(kāi)發(fā)。

我們下面試著用建模的方式對(duì)上圖中的功能點(diǎn)進(jìn)行大致面向?qū)ο笤O(shè)計(jì)，盡量提取變化點(diǎn)。

【簡(jiǎn)單用例】

根據(jù)上圖的基本功能我們確定兩組用例，第一組是【客戶Custom】發(fā)起的所有動(dòng)作，第二組是【后臺(tái)管理人員Admin】，比如配貨部門、訂單審核部門等等。這里純粹是為了演示建模的功能不是特地的項(xiàng)目實(shí)踐，所以功能簡(jiǎn)單明了。

1.2圖

客戶首次進(jìn)去平臺(tái)之后肯定是需要進(jìn)行賬戶的【注冊(cè)】,有注冊(cè)就會(huì)有【注銷】，這里的注銷不是退出系統(tǒng)的意思，而是注銷在當(dāng)前平臺(tái)的使用，就跟銷戶是一個(gè)意思。

(當(dāng)然有人會(huì)覺(jué)得注銷不妥，電子商務(wù)平臺(tái)是不應(yīng)該有注銷的，這只是主觀的設(shè)計(jì)而已，每個(gè)人的想法不同所以可以取長(zhǎng)補(bǔ)短 ，我覺(jué)得有一個(gè)正面的注銷功能很好，可以讓用戶進(jìn)行使用，到底如何使用我們這里就不分析了。)

成為正式用戶之后就可以挑選自己喜歡的商品進(jìn)行【下訂單】，下訂單后就會(huì)進(jìn)入平臺(tái)運(yùn)行管理的流程的，客戶會(huì)隨時(shí)收到平臺(tái)發(fā)過(guò)來(lái)的流程信息反饋。所以這里有一個(gè)【短信管理】用例，該用例當(dāng)然會(huì)包含 【刪除信息】、【讀取信息】、【回復(fù)信息】包含的子用例。

(當(dāng)然可能我分析的不夠細(xì)致或者有問(wèn)題的地方，由于我也是最近接觸UML建模所以可能有點(diǎn)不熟悉，對(duì)UML有興趣的朋友可以參考相關(guān)專業(yè)書籍。)

1.3圖

后臺(tái)管理人員需要對(duì)客戶下的訂單進(jìn)行【配送】處理，配送環(huán)節(jié)將牽扯到【客戶信息】、【更新訂單狀態(tài)】、【打印配送信息】用例，對(duì)【打印配送信息】

功能需要【發(fā)送收貨信息】給用戶，告知用戶貨物已經(jīng)發(fā)出。這里還包括一個(gè)泛化的用例【物品清單、配送地址】，在【打印配送信息】功能里面需要具體的打印出跟配貨信息相關(guān)的信息。

（這里提一下UML用例圖其實(shí)是通過(guò)縱橫向的方式來(lái)尋找系統(tǒng)的所有功能點(diǎn)，縱向是系統(tǒng)的所有功能，橫向是系統(tǒng)的外部調(diào)用者。）

【領(lǐng)域模型】

根據(jù)上述用例我們基本能捕獲到大致的系統(tǒng)功能，下面我們通過(guò)創(chuàng)建UML類圖來(lái)描述領(lǐng)域模型。

模型的創(chuàng)建要根據(jù)上一步的用例圖來(lái)進(jìn)行分析，只要?jiǎng)?chuàng)建的模型能滿足用例的所有功能點(diǎn)就已經(jīng)完成了一個(gè)大致輪廓。有些隱藏的模型是需要不斷的重構(gòu)才能逐漸的浮現(xiàn)出來(lái)。

1.4圖

大致的模型已經(jīng)創(chuàng)建出來(lái)，這只能算是一個(gè)基本的草圖形式的建模，還有幾個(gè)過(guò)程沒(méi)有走完，比如：反復(fù)的重構(gòu)、與領(lǐng)域?qū)＜矣懻撃Ｐ偷臏?zhǔn)確性、與DBA進(jìn)行溝通等等，這些都是DDD的整個(gè)范疇。

有了領(lǐng)域模型之后我們基本算是有了一個(gè)大致的業(yè)務(wù)方向，剩下的就是精益求精的過(guò)程，不斷的去分析深層業(yè)務(wù)關(guān)系。

【場(chǎng)景序列】

得出了領(lǐng)域模型之后我們需要對(duì)它進(jìn)行一個(gè)基本的驗(yàn)證，也就是看看模型是否能滿足所有的功能需求。最常用的就是通過(guò)序列圖來(lái)走查場(chǎng)景，對(duì)我們創(chuàng)建的領(lǐng)域模型進(jìn)行逐步驗(yàn)證。

由于時(shí)間關(guān)系我這里就不給出所有的序列圖了，只給出有代表性的序列【配送】。

1.5圖

由于怕截圖片太大所以給出關(guān)鍵的序列流程，能表達(dá)其意思就行了。

這是經(jīng)典DDD調(diào)用序列，對(duì)上面具體的對(duì)象不是很清楚的不要緊后面有專門的示例進(jìn)行全面分析。

#p#

【1.2】模式

模式相比大家都知道是什么意思，一些通用的思考問(wèn)題的思路、解決方法、分析方法。當(dāng)然在DDD領(lǐng)域也有很多模式供我們學(xué)習(xí)和使用，在需求階段講解的是行為模式在分析階段有分析模式，在設(shè)計(jì)階段有設(shè)計(jì)模式，在實(shí)現(xiàn)階段有實(shí)現(xiàn)模式，還有宏觀的架構(gòu)模式。

那么在進(jìn)行領(lǐng)域建模的時(shí)候有些前人總結(jié)出來(lái)的分析模式可以供我們參考。

【1.2.1】四色原型模式

四色原型模式是我接觸的第一個(gè)分析模式，當(dāng)然目前也是發(fā)現(xiàn)它確實(shí)很好用，所以給同志們分享一下。

四色原型模式是能幫助我們找出業(yè)務(wù)當(dāng)中的核心模型，也就是說(shuō)核型模式應(yīng)該具備幾個(gè)比較重要的特征的。

基本上想要根據(jù)UML用例圖找出領(lǐng)域模型需要使用名\動(dòng)詞法找出大概的模型，然后順著領(lǐng)域模型一點(diǎn)一點(diǎn)完善、發(fā)掘，從而找出相關(guān)的實(shí)體模型。但是有些實(shí)體模型是一眼就能看出來(lái)的，就比如上例中的【用戶】、【訂單】、【消息】都可以定義為實(shí)體類型，也就是當(dāng)前小示例中的核心領(lǐng)域模型。

看一下四色原型模式的結(jié)構(gòu)圖：

1.6圖

對(duì)照四色原型模式我們很容易發(fā)現(xiàn)模型中的核型實(shí)體模型，很明顯對(duì)照上面的領(lǐng)域模型我們確實(shí)都是核心模型。

1.7圖

對(duì)照該模式我們會(huì)發(fā)現(xiàn)這里的商品其實(shí)也是核心實(shí)體才對(duì)，但是我們能很快發(fā)現(xiàn)我們忽視它了，商品也存在狀態(tài)和一些值類型才對(duì)，比如商品的使用狀態(tài)是不是沒(méi)貨、商品的詳細(xì)屬性是不是也存在獨(dú)立的值對(duì)象。當(dāng)然這些要看當(dāng)前項(xiàng)目需求而定。太范式的設(shè)計(jì)會(huì)帶來(lái)一些問(wèn)題，有性能問(wèn)題、有開(kāi)發(fā)成本問(wèn)題，這些都要進(jìn)行詳細(xì)的討論才能最終確定，所以反范式設(shè)計(jì)就出現(xiàn)了。

原文鏈接：http://www.cnblogs.com/wangiqngpei557/archive/2013/04/07/3005890.html