建站
咨詢
售后
建站咨詢
新聞中心
最近在研究DDD頗有收獲，所以整理出來跟大家分享，共同進(jìn)步！
創(chuàng)新互聯(lián)建站是一家集網(wǎng)站建設(shè),湘陰企業(yè)網(wǎng)站建設(shè),湘陰品牌網(wǎng)站建設(shè),網(wǎng)站定制,湘陰網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,湘陰網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
我們在設(shè)計業(yè)務(wù)系統(tǒng)的時候都會存在一個非常棘手而又無法回避的問題“業(yè)務(wù)擴(kuò)展性”、“業(yè)務(wù)靈活性、”面向?qū)ο蠡?，盡管我們熟練掌握設(shè)計思想、設(shè)計模式、設(shè)計原則等等關(guān)于如何設(shè)計靈活性的系統(tǒng)設(shè)計理論，但是我們似乎都沒有將它們運(yùn)用到真正業(yè)務(wù)系統(tǒng)設(shè)計、開發(fā)當(dāng)中去，為什么？這樣的疑問如果對有心想設(shè)計好系統(tǒng)的朋友來說肯定是很早就出現(xiàn)過，只是無法解決，因為我們目前使用的設(shè)計方法是與面向?qū)ο笤O(shè)計背道而馳的。
漫長的數(shù)據(jù)庫驅(qū)動開發(fā)歷史，導(dǎo)致我們根本無法脫離這個環(huán)境進(jìn)行學(xué)習(xí)和實戰(zhàn)。從教科書再到真正的企業(yè)項目開發(fā)都是先設(shè)計數(shù)據(jù)庫然后進(jìn)行邏輯的編寫，大部分的業(yè)務(wù)邏輯都是存在于UI和數(shù)據(jù)庫【存儲過程、自定義函數(shù)】中，所謂的三層架構(gòu)中的BLL層其實是形同虛設(shè)，根本沒有起到它應(yīng)有的作用。
當(dāng)然我們不是大師，我們只是普通的程序員，希望有一種方法論能引導(dǎo)我們進(jìn)行真確的系統(tǒng)設(shè)計。在未接觸DDD之前，我也一樣有著同樣的困擾，我們編寫很多的開發(fā)框架、組件、插件、服務(wù)等等太多太多類似能提高開發(fā)效率的功能，夢想著自己的系統(tǒng)能想真正如書上所說的搭積木一樣搭建自己的系統(tǒng)，我們捫心問自己真的可以做到嗎？我嘆息，很難；
我一直感覺復(fù)雜的系統(tǒng)設(shè)計對我來說真的沒有辦法應(yīng)付，只能憑借細(xì)心和對業(yè)務(wù)的熟悉程度，沒有正確的理論引導(dǎo)，那些所謂的大師們的設(shè)計思想的書真的對我?guī)椭淮?，看了不知道如何進(jìn)行運(yùn)用。時至今日我終于可以感覺到那種神秘的設(shè)計確實可以帶領(lǐng)我們穿越復(fù)發(fā)的系統(tǒng)設(shè)計。當(dāng)然這條路對剛開始接觸DDD的朋友來說會存在很多問題，恰巧在下有幸接觸DDD有點心得，也通過分析了一個小的系統(tǒng)進(jìn)行DDD的開發(fā)工作，所以在這里把自己最近研究的心得和疑惑跟同行們分享，如有不對的地方請多指點。
【1.1】疑問
在任何一項新技術(shù)被采納之前必須要解決幾個關(guān)鍵的問題，這也是我們程序員考慮使用一項新技術(shù)的必須過程，它的出現(xiàn)能解決哪些問題和將會帶來哪些問題。DDD固然很好，但是要想把它運(yùn)用到自己的項目當(dāng)中去，是需要很多時間和精力來分析它的實施過程和對項目團(tuán)隊的要求。當(dāng)然人為的因素和外在的環(huán)境問題我們這里不考慮，畢竟那些是我們無法改變的事情，這里只討論和我們密切相關(guān)的問題。
【1.1.1】UML何用
做程序開發(fā)的我們都知道UML是干什么的，簡單的講它屬于一種標(biāo)準(zhǔn)的系統(tǒng)建模語言，便于我們對系統(tǒng)進(jìn)行分析和團(tuán)隊之間的合作。既然是語言它的主要作用是溝通，技術(shù)人員和分析人間的橋梁。但是到目前為止我沒有發(fā)現(xiàn)它真正幫助過我進(jìn)行系統(tǒng)分析和設(shè)計，上面已經(jīng)提過其實是兩種開發(fā)方法論恰恰相反，所以導(dǎo)致根本無法集成，就拿UML中的類圖來講，我們都是先設(shè)計數(shù)據(jù)庫然后進(jìn)行開發(fā)何來的對象？直接是表驅(qū)動，通過一些快速的代碼生成器進(jìn)行界面和一些通用的單表的CDUS代碼的生成，程序中根本沒有對象的概念，業(yè)務(wù)邏輯遍布UI層[圖1.1]。UML畫的類圖無法在程序中表現(xiàn)出來，所以它無法在絕大部分的企業(yè)中普及。
1.1圖
上圖假設(shè)是一個簡單的模擬B2C的基本功能，通過它我們能簡單的了解到我們的系統(tǒng)開發(fā)的問題所在。
以上圖中的系統(tǒng)結(jié)構(gòu)，我們很難知道系統(tǒng)的具體業(yè)務(wù)邏輯，更別說對系統(tǒng)的擴(kuò)展性能有保障。這樣的結(jié)構(gòu)在開發(fā)初期沒有什么問題，但是在后期的維護(hù)工作中將是費事費力的，最后的項目代碼無法進(jìn)行的很好的閱讀，也就無法很好的進(jìn)行穩(wěn)定性維護(hù)。特別是業(yè)務(wù)系統(tǒng)，它的需求會變的很多甚至很變態(tài)，如果按照這種方式進(jìn)行維護(hù)，那么界面上的代碼會越來越多，而BLL、DAL中的重復(fù)性的功能方法也會急劇變多或者是服務(wù)層的相同功能不同方法參數(shù)的代碼會越來越多。其實到最后也就談不上什么藝術(shù)了，更別說項目進(jìn)行產(chǎn)品化后上市。
那么UML真的起不到作用嗎？或者說我們真的與UML無緣？當(dāng)然不是，而是我們沒有使用相關(guān)的軟件設(shè)計、開發(fā)方法論而已。按照DDD的思想，我們是業(yè)務(wù)驅(qū)動開發(fā)，先進(jìn)行領(lǐng)域模型的創(chuàng)建，然后才是數(shù)據(jù)庫的設(shè)計。其實只有按照DDD的開發(fā)理論來才能最大的保證系統(tǒng)的擴(kuò)展性和業(yè)務(wù)整潔性，才能保證項目的良性循環(huán)。
#p#
【1.1.2】領(lǐng)域建模
“領(lǐng)域建?！焙艹橄笠埠芩囆g(shù)的一個詞，它是軟件設(shè)計藝術(shù)中的一個境界。
我們常常接觸面向?qū)ο缶幊?、面向?qū)ο笤O(shè)計的書籍或者話題，大家都對它有獨特的見解，但是我們始終沒有將它用作真正的系統(tǒng)性開發(fā)中去。但是在編寫框架的時候我們都能得心應(yīng)手的進(jìn)行面向?qū)ο笤O(shè)計，為了保證框架的靈活性乃至最大的擴(kuò)展性就要進(jìn)行最細(xì)粒度的分解、抽象、提取，這些在非數(shù)據(jù)庫系統(tǒng)開發(fā)中都沒有問題。然而最大的問題出在對象需要與數(shù)據(jù)庫結(jié)合，對象的生命周期持久化在數(shù)據(jù)庫中，生也數(shù)據(jù)庫死也數(shù)據(jù)庫。所以這里的問題就是如何在面向?qū)ο笤O(shè)計與關(guān)系型數(shù)據(jù)庫設(shè)計之間平滑的過度持久化。這是領(lǐng)域驅(qū)動開發(fā)的最大的問題，也是很多面向DDD框架的開發(fā)重點。
在上圖中我們目睹了以數(shù)據(jù)庫驅(qū)動后系統(tǒng)的大致結(jié)構(gòu)，假設(shè)我們需要保證功能模塊的最大的擴(kuò)展性我們在編寫數(shù)據(jù)庫驅(qū)動代碼的時候，很難抽象出復(fù)雜的變化點，因為都是貧血型的業(yè)務(wù)模型或者說根本不知道變化點在什么地方。而且并不是普通的開發(fā)人員能發(fā)掘到的，當(dāng)然數(shù)據(jù)庫驅(qū)動開發(fā)也一樣可以進(jìn)行靈活設(shè)計、開發(fā)，但是這樣畢竟對開發(fā)人員要求很高，他需要具備很強(qiáng)的面向?qū)ο笤O(shè)計能力，在不污染現(xiàn)有的代碼的情況下進(jìn)行擴(kuò)展性重構(gòu)。至少我的經(jīng)驗告訴我很難，而且在需求階段并沒有一個完整的大局觀，很容易造成頭重腳輕。對后期的系統(tǒng)開發(fā)進(jìn)度也很難控制，因為無法確定每個功能模塊到底存在哪些接口。
所以我們還是朝著光明的道路前進(jìn)，掌握DDD進(jìn)行系統(tǒng)設(shè)計開發(fā)。
我們下面試著用建模的方式對上圖中的功能點進(jìn)行大致面向?qū)ο笤O(shè)計，盡量提取變化點。
【簡單用例】
根據(jù)上圖的基本功能我們確定兩組用例，第一組是【客戶Custom】發(fā)起的所有動作，第二組是【后臺管理人員Admin】，比如配貨部門、訂單審核部門等等。這里純粹是為了演示建模的功能不是特地的項目實踐，所以功能簡單明了。
1.2圖
客戶首次進(jìn)去平臺之后肯定是需要進(jìn)行賬戶的【注冊】,有注冊就會有【注銷】，這里的注銷不是退出系統(tǒng)的意思，而是注銷在當(dāng)前平臺的使用，就跟銷戶是一個意思。
(當(dāng)然有人會覺得注銷不妥，電子商務(wù)平臺是不應(yīng)該有注銷的，這只是主觀的設(shè)計而已，每個人的想法不同所以可以取長補(bǔ)短 ，我覺得有一個正面的注銷功能很好，可以讓用戶進(jìn)行使用，到底如何使用我們這里就不分析了。)
成為正式用戶之后就可以挑選自己喜歡的商品進(jìn)行【下訂單】，下訂單后就會進(jìn)入平臺運(yùn)行管理的流程的，客戶會隨時收到平臺發(fā)過來的流程信息反饋。所以這里有一個【短信管理】用例，該用例當(dāng)然會包含 【刪除信息】、【讀取信息】、【回復(fù)信息】包含的子用例。
(當(dāng)然可能我分析的不夠細(xì)致或者有問題的地方，由于我也是最近接觸UML建模所以可能有點不熟悉，對UML有興趣的朋友可以參考相關(guān)專業(yè)書籍。)
1.3圖
后臺管理人員需要對客戶下的訂單進(jìn)行【配送】處理，配送環(huán)節(jié)將牽扯到【客戶信息】、【更新訂單狀態(tài)】、【打印配送信息】用例，對【打印配送信息】
功能需要【發(fā)送收貨信息】給用戶，告知用戶貨物已經(jīng)發(fā)出。這里還包括一個泛化的用例【物品清單、配送地址】，在【打印配送信息】功能里面需要具體的打印出跟配貨信息相關(guān)的信息。
（這里提一下UML用例圖其實是通過縱橫向的方式來尋找系統(tǒng)的所有功能點，縱向是系統(tǒng)的所有功能，橫向是系統(tǒng)的外部調(diào)用者。）
【領(lǐng)域模型】
根據(jù)上述用例我們基本能捕獲到大致的系統(tǒng)功能，下面我們通過創(chuàng)建UML類圖來描述領(lǐng)域模型。
模型的創(chuàng)建要根據(jù)上一步的用例圖來進(jìn)行分析，只要創(chuàng)建的模型能滿足用例的所有功能點就已經(jīng)完成了一個大致輪廓。有些隱藏的模型是需要不斷的重構(gòu)才能逐漸的浮現(xiàn)出來。
1.4圖
大致的模型已經(jīng)創(chuàng)建出來，這只能算是一個基本的草圖形式的建模，還有幾個過程沒有走完，比如：反復(fù)的重構(gòu)、與領(lǐng)域?qū)＜矣懻撃Ｐ偷臏?zhǔn)確性、與DBA進(jìn)行溝通等等，這些都是DDD的整個范疇。
有了領(lǐng)域模型之后我們基本算是有了一個大致的業(yè)務(wù)方向，剩下的就是精益求精的過程，不斷的去分析深層業(yè)務(wù)關(guān)系。
【場景序列】
得出了領(lǐng)域模型之后我們需要對它進(jìn)行一個基本的驗證，也就是看看模型是否能滿足所有的功能需求。最常用的就是通過序列圖來走查場景，對我們創(chuàng)建的領(lǐng)域模型進(jìn)行逐步驗證。
由于時間關(guān)系我這里就不給出所有的序列圖了，只給出有代表性的序列【配送】。
1.5圖
由于怕截圖片太大所以給出關(guān)鍵的序列流程，能表達(dá)其意思就行了。
這是經(jīng)典DDD調(diào)用序列，對上面具體的對象不是很清楚的不要緊后面有專門的示例進(jìn)行全面分析。
#p#
【1.2】模式
模式相比大家都知道是什么意思，一些通用的思考問題的思路、解決方法、分析方法。當(dāng)然在DDD領(lǐng)域也有很多模式供我們學(xué)習(xí)和使用，在需求階段講解的是行為模式在分析階段有分析模式，在設(shè)計階段有設(shè)計模式，在實現(xiàn)階段有實現(xiàn)模式，還有宏觀的架構(gòu)模式。
那么在進(jìn)行領(lǐng)域建模的時候有些前人總結(jié)出來的分析模式可以供我們參考。
【1.2.1】四色原型模式
四色原型模式是我接觸的第一個分析模式，當(dāng)然目前也是發(fā)現(xiàn)它確實很好用，所以給同志們分享一下。
四色原型模式是能幫助我們找出業(yè)務(wù)當(dāng)中的核心模型，也就是說核型模式應(yīng)該具備幾個比較重要的特征的。
基本上想要根據(jù)UML用例圖找出領(lǐng)域模型需要使用名\動詞法找出大概的模型，然后順著領(lǐng)域模型一點一點完善、發(fā)掘，從而找出相關(guān)的實體模型。但是有些實體模型是一眼就能看出來的，就比如上例中的【用戶】、【訂單】、【消息】都可以定義為實體類型，也就是當(dāng)前小示例中的核心領(lǐng)域模型。
看一下四色原型模式的結(jié)構(gòu)圖：
1.6圖
對照四色原型模式我們很容易發(fā)現(xiàn)模型中的核型實體模型，很明顯對照上面的領(lǐng)域模型我們確實都是核心模型。
1.7圖
對照該模式我們會發(fā)現(xiàn)這里的商品其實也是核心實體才對，但是我們能很快發(fā)現(xiàn)我們忽視它了，商品也存在狀態(tài)和一些值類型才對，比如商品的使用狀態(tài)是不是沒貨、商品的詳細(xì)屬性是不是也存在獨立的值對象。當(dāng)然這些要看當(dāng)前項目需求而定。太范式的設(shè)計會帶來一些問題，有性能問題、有開發(fā)成本問題，這些都要進(jìn)行詳細(xì)的討論才能最終確定，所以反范式設(shè)計就出現(xiàn)了。
文章標(biāo)題：.NET領(lǐng)域驅(qū)動設(shè)計—初嘗
文章分享：http://www.dlmjj.cn/article/dpjhhos.html
