為了的更好的理解DDD，我們先簡(jiǎn)單介紹下Transaction Script
Transaction Script模式遵循的是過程式開發(fā)風(fēng)格而不是面向?qū)ο蠓椒üＭǔ＃瑸槊總€(gè)業(yè)務(wù)事務(wù)創(chuàng)建一個(gè)單獨(dú)的方法，并將它們組合起來放入某種靜態(tài)管理程序或服務(wù)類抄邀。每個(gè)過程都包含了完成業(yè)務(wù)事務(wù)所需的所有業(yè)務(wù)邏輯阴孟，包括工作流晌纫、業(yè)務(wù)規(guī)則和數(shù)據(jù)庫持久化驗(yàn)證檢查。
由于Transaction Script的特征永丝，分層的一般架構(gòu)
Transaction Script模式的一個(gè)優(yōu)勢(shì)是它易于理解锹漱，很快就可以讓團(tuán)隊(duì)新成員上手而不需要具有該模式的預(yù)備知識(shí)。當(dāng)出現(xiàn)新需求時(shí)慕嚷，很容易向該類中添加更多方法哥牍，而不用擔(dān)心影響或破壞現(xiàn)有功能。
Transaction Script模式非常適于那些邏輯中只包含很少或不包含可能增長(zhǎng)的功能集合的小型應(yīng)用程序喝检，以及有不熟悉面向?qū)ο缶幊谈拍畹某跫?jí)開發(fā)者的團(tuán)隊(duì)
1.DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)
1.1.領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心
軟件的核心是為用戶解決領(lǐng)域相關(guān)問題的能力嗅辣。
1.2.分層
1.3.核心元素
- entity
一些對(duì)象主要不是由它們的屬性定義的，而是通過標(biāo)志進(jìn)行區(qū)分的挠说。比如一個(gè)人澡谭，不是通過身高、體重损俭、膚色等屬性定義的蛙奖，一般我們使用身份證來標(biāo)識(shí)。
- value object
很多對(duì)象沒有概念上的標(biāo)識(shí)撩炊，它們表述了一個(gè)事物的某種特征外永。比如顏色、溫度拧咳、長(zhǎng)短等伯顶。
- repository
我們可以通過對(duì)象之間的關(guān)聯(lián)來找到對(duì)象，但當(dāng)它處于生命周期的中間時(shí)骆膝，必須要有一個(gè)起點(diǎn)祭衩，以便從這個(gè)起點(diǎn)遍歷到一個(gè)entity或value object。比如現(xiàn)在有訂單id(123)阅签，需要構(gòu)建Order aggregate對(duì)象時(shí)掐暮，我們就可以通過repository來完成這個(gè)過程。
- service
有時(shí)政钟，對(duì)象不是一個(gè)事物路克，而是某種操作樟结。比如購買商品時(shí)的購買行為等。
- aggregate
aggregate就是一組相關(guān)對(duì)象的集合精算，我們把它作為數(shù)據(jù)修改的單元瓢宦。每個(gè)aggregate都有一個(gè)根(root)和一個(gè)邊界(boundary)。比如在下面的圖片中灰羽，一共有四個(gè)aggregate驮履，分別是Customer、Order廉嚼、Product玫镐、Product Categories。
[圖片上傳失敗...(image-13fbb0-1540213534191)]
- factory
在創(chuàng)建整個(gè)aggregate時(shí)怠噪，創(chuàng)建工作可能變得很復(fù)雜恐似，比如上圖中Order aggregate的創(chuàng)建。對(duì)于這類的創(chuàng)建動(dòng)作舰绘，我們可以使用Factory模型蹂喻。
1.3.1.factory與repository的區(qū)別
雖然factory與repository都是為了創(chuàng)建aggregate對(duì)象葱椭，但是兩者的職責(zé)是有著非常明顯的劃分的捂寿，其中factory負(fù)責(zé)創(chuàng)建一個(gè)新的aggregate對(duì)象，而repository則是從已有的存儲(chǔ)系統(tǒng)中重建aggregate對(duì)象孵运。
1.3.2.是不是所有的entity都需要引入repository秦陋？
在使用ddd架構(gòu)時(shí)，我們?cè)谝雛epository時(shí)治笨，非常容易犯的一個(gè)錯(cuò)誤驳概，就是為每個(gè)entity都引入repository。為什么會(huì)這么做呢旷赖？
因?yàn)樵赥ransaction Script中顺又，通常一個(gè)表，一個(gè)dao等孵；所以我們?cè)赿dd中使用repository時(shí)稚照，自然而然的為每個(gè)entity引入一個(gè)repository。
1.4.DDD不僅僅是分層
在使用ddd時(shí)俯萌，我們?nèi)菀紫萑胍粋€(gè)誤區(qū)果录，就是根據(jù)ddd引入了大量的分層代碼。雖然我們的代碼是根據(jù)ddd的分層方式去組織咐熙，但是實(shí)際的業(yè)務(wù)邏輯卻以及使用Transaction Script的方式在處理弱恒。是什么原因?qū)е聦?dǎo)致的呢？
- 1.對(duì)ddd理解不夠透徹
- 2.沒有抓住核心的業(yè)務(wù)
- 3.Transaction Script的影響
在上面的幾個(gè)因素中棋恼，只能通過不斷的實(shí)踐ddd項(xiàng)目返弹，才能夠獲得深入的了解锈玉，并無什么銀彈。
1.5.充血模型與貧血模型的區(qū)別
待補(bǔ)充...
