- 相關(guān)推薦
經(jīng)典的領(lǐng)域驅(qū)動設(shè)計(jì)在代碼實(shí)踐方面的心得體會
創(chuàng)建領(lǐng)域?qū)ο蟛捎脴?gòu)造函數(shù)或者工廠，如果用工廠時需要依賴于領(lǐng)域服務(wù)或倉儲，則通過構(gòu)造函數(shù)注入到工廠；領(lǐng)域服務(wù)可以依賴倉儲或聚合根；
一個聚合根配備一個倉儲；
倉儲應(yīng)理解為一個在內(nèi)存中維護(hù)一系列聚合根的集合；
一個聚合有一個聚合根，聚合根也是一個Entity，聚合內(nèi)還有其他Entity和Value Object；
倉儲提供的方法應(yīng)該總是接受聚合根或返回聚合根，不能返回聚合內(nèi)的其他Entity或Value Object；
聚合內(nèi)的非跟的Entity以及Value Object之間不要相互引用，聚合內(nèi)的所有Child可以對根Entity持有引用，如果一個Child Entity需要和另外一個Child Entity交互，則因該通過聚合根完成；
聚合根與聚合根之間應(yīng)避免直接對象引用，而應(yīng)該采用ID關(guān)聯(lián)；聚合根與聚合根之間的關(guān)系不像聚合內(nèi)的Entity之間這么強(qiáng)烈內(nèi)聚，它們之間僅僅是某種比較弱的關(guān)聯(lián)關(guān)系，每個聚合根都有其獨(dú)立的生命周期；
聚合根之間通過ID關(guān)聯(lián)的好處是：不會因?yàn)長oad一個聚合根而把其他關(guān)聯(lián)的聚合根一起Load出來，這樣也避免了Load一個聚合根會把整個數(shù)據(jù)庫Load出來的風(fēng)險；
我們應(yīng)該盡量減少關(guān)聯(lián)，盡量做到單向關(guān)聯(lián)，只保留確實(shí)需要處理的經(jīng)常需要用到的遍歷方向的關(guān)聯(lián)；
如果一個操作僅由一個聚合根就可以完成，那么直接調(diào)用該聚合根完成即可；
如果一個操作我們會遇見到會由多個聚合根相互協(xié)作完成，那么需要為該操作建立領(lǐng)域服務(wù)，在領(lǐng)域服務(wù)中以過程化的方式來一步步調(diào)用相關(guān)的聚合根完成整個業(yè)務(wù)操作；
切忌不要因?yàn)轭I(lǐng)域服務(wù)的引入讓聚合根變得貧血，聚合根應(yīng)該有職責(zé)還是必須要由聚合根來承擔(dān)；
聚合根內(nèi)不要依賴領(lǐng)域服務(wù)或倉儲，如果你發(fā)現(xiàn)一個聚合根的職責(zé)需要依賴于某個領(lǐng)域服務(wù)或倉儲來幫忙完成一些其他的邏輯（像判斷業(yè)務(wù)規(guī)則之類），那么通常你要考慮這個職責(zé)不應(yīng)該由該聚合根來承擔(dān)，而應(yīng)該建立合適的領(lǐng)域服務(wù)來承擔(dān)；聚合根的主要職責(zé)是管理其內(nèi)聚的所有Child Entity或Value Object的業(yè)務(wù)完整性；
領(lǐng)域驅(qū)動設(shè)計(jì)時，為對象分配職責(zé)時，可以參考信息專家模式：將職責(zé)分配給擁有執(zhí)行該職責(zé)所需信息的人；如果一個聚合根看起來擁有執(zhí)行某個職責(zé)所需的信息，但沒包含全部所需信息，此時則不應(yīng)該將該職責(zé)分配給該聚合根，因?yàn)閺?qiáng)行分配給它，會導(dǎo)致該聚合根沒有內(nèi)聚性，因?yàn)閯荼貢蕾囉谄渌念I(lǐng)域?qū)ο蠡蝾I(lǐng)域服務(wù)或倉儲；
聚合內(nèi)的所有實(shí)體和值對象應(yīng)該總是一起被取出來一起被保存，因?yàn)橐粋�聚合是一個數(shù)據(jù)持久化的單元，不需要考慮將整個聚合根取出來有性能問題，因?yàn)槿魏我粋�聚合根都有明確的邊界。目前的內(nèi)存緩存框架都已發(fā)展的比較成熟，性能已經(jīng)不是問題；如MongoDb，MemCache，NoSQL，等等；
不要給倉儲提供一些目的是為了為界面提供顯示數(shù)據(jù)的接口，倉儲提供的所有接口僅為領(lǐng)域模型使用；
要學(xué)習(xí)CQRS架構(gòu)，要知道我們應(yīng)該將應(yīng)用程序的業(yè)務(wù)邏輯處理部分（即用戶命令響應(yīng)部分）和查詢部分分離；我們應(yīng)該用兩個不同的技術(shù)來實(shí)現(xiàn)這兩個部分的實(shí)現(xiàn)；用DDD領(lǐng)域模型來實(shí)現(xiàn)命令部分；用最快的查詢引擎來實(shí)現(xiàn)查詢部分；
如果要采用CQRS架構(gòu)，我們需要考慮一個成熟可靠的底層框架，否則很容易導(dǎo)致命令端產(chǎn)生的領(lǐng)域?qū)ο蟮臓顟B(tài)無法同步（后者丟失）到查詢端的存儲中；
領(lǐng)域服務(wù)依賴倉儲時，工廠依賴于領(lǐng)域服務(wù)或倉儲時，都因該采用構(gòu)造函數(shù)注入的方式，這樣可以避免領(lǐng)域模型中不會出現(xiàn)DependencyResolver.Resolve<T>()這樣的語句；
不要把倉儲理解為DAO，倉儲屬于領(lǐng)域模型的一部分，代表了領(lǐng)域模型向外提供接口的一部分，而DAO是表示數(shù)據(jù)庫向上層提供的接口表示；
領(lǐng)域?qū)ο笊系膶傩钥梢跃哂術(shù)et和set，因?yàn)槲覀兤綍r所理解的對象不是真正的對象，而是某個事實(shí)的描述，比如圖書管理系統(tǒng)中的一個Book對象，表示圖書管中放著一本書，然后該書可能有一個入庫時間。現(xiàn)實(shí)生活正的話，書本的入庫時間絕對不可能變化，但是軟件中的Book因?yàn)椴皇钦嬲默F(xiàn)實(shí)生活中的書本，而只是表示圖書館中有一本書這個事實(shí)的描述，我們當(dāng)然可以修改這個事實(shí)，因?yàn)槲覀兛赡芤驗(yàn)橹霸跁救霂鞎r所輸入的入庫時間是錯的，需要修改該入庫時間，此時就有提供set的必要了。所以，理論上任何一個Entity，除了ID之外，其他所有屬性都可以更改，因?yàn)檫@些屬性并不表示現(xiàn)實(shí)生活中的真正對象的特征，而僅僅只是對一個事實(shí)的描述；剛開始Book對象對書本入庫這個事實(shí)的描述可能有問題，此時我們就需要修改該Book的屬性；我想這個例子已經(jīng)充分說明為什么可以提供get和set了；
不要總是零散的不加任何分組的設(shè)計(jì)Entity的屬性，因?yàn)橛行⿲傩栽谶壿嬌匣驑I(yè)務(wù)上就是內(nèi)聚的，代表一個完整的概念，比如Country,Province,City,Town,Street，等這些屬性表示一個地址的信息，此時我們應(yīng)該設(shè)計(jì)一個Address對象來表示該地址信息，此時該Address就是一個值對象。所以我們在設(shè)計(jì)Entity的屬性時，要好好想想，哪些子屬性其實(shí)在業(yè)務(wù)上是一個完整的概念，此時我們就需要考慮將這些相關(guān)的屬性設(shè)計(jì)為一個值對象；
切忌值對象必須是只讀的，值對象之所以叫值對象最主要的是因?yàn)樗硎疽粋�值，而不是一個對象；值是不會變化的，是一個明確含義的不變的事物，比如3表示一個值，表述數(shù)量是3，3永遠(yuǎn)不能變化；所以說，世界之所以存在，是因?yàn)橛羞@些永恒不變的值對象的存在；我們只要把值對象理解為3，“abcd”這樣的永恒不變的值就行了；
不要讓領(lǐng)域模型去模擬現(xiàn)實(shí)，模擬用戶（軟件使用者）與領(lǐng)域模型交互的過程；領(lǐng)域模型要實(shí)現(xiàn)的應(yīng)該是用戶的需求，領(lǐng)域模型中不應(yīng)該包含用戶的成分，想想只有空杯子才能裝水的道理，即無為以之用的道理就明白了；所以，我們在設(shè)計(jì)領(lǐng)域模型時首先要明白領(lǐng)域模型要完成的事情是什么；這方面，多看看用例圖，就知道軟件該做的事情了，推薦大家看的書是：Craig Larman寫的《UML和模式應(yīng)用》一書，非常經(jīng)典；
暫時就寫這么多吧，以后想到什么再補(bǔ)上，呵呵。
【經(jīng)典的領(lǐng)域驅(qū)動設(shè)計(jì)在代碼實(shí)踐方面的心得體會】相關(guān)文章：
幼兒園語言領(lǐng)域方面的教案（精選23篇）10-06
活動設(shè)計(jì)健康領(lǐng)域教案12-19
活動設(shè)計(jì)科學(xué)領(lǐng)域教案08-26
設(shè)計(jì)方崗位職責(zé)04-17
幼兒活動設(shè)計(jì)健康領(lǐng)域教案02-16
活動設(shè)計(jì)健康領(lǐng)域教案(7篇)12-24
活動設(shè)計(jì)健康領(lǐng)域教案7篇12-20
健康領(lǐng)域心得體會02-20
任務(wù)驅(qū)動型作文05-10