建站
咨詢
售后
建站咨詢
新聞中心
DDD即領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，是一種建模方法論，強(qiáng)調(diào)通過(guò)分析建模、再設(shè)計(jì)實(shí)現(xiàn)，而不是數(shù)據(jù)庫(kù)表驅(qū)動(dòng)。
創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括松原網(wǎng)站建設(shè)、松原網(wǎng)站制作、松原網(wǎng)頁(yè)制作以及松原網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，松原網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到松原省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
DDD解決的是核心復(fù)雜業(yè)務(wù)設(shè)計(jì)，特別強(qiáng)調(diào)的是“核心”與”復(fù)雜”，DDD只適用于業(yè)務(wù)系統(tǒng)。
DDD簡(jiǎn)化業(yè)務(wù)系統(tǒng)的實(shí)現(xiàn)，讓業(yè)務(wù)邏輯高度內(nèi)聚，聚合之間通過(guò)聚合根ID引用與領(lǐng)域事件松耦合，正是高內(nèi)聚低耦合能讓項(xiàng)目代碼隨著業(yè)務(wù)需求的不斷迭代保持整潔。
通過(guò)四層架構(gòu)設(shè)計(jì)/六邊形架構(gòu)設(shè)計(jì)實(shí)現(xiàn)與基礎(chǔ)設(shè)施、框架的解偶。
DDD也解決了微服務(wù)的拆分問(wèn)題。
DDD解決的是業(yè)務(wù)問(wèn)題，通過(guò)事件風(fēng)暴識(shí)別領(lǐng)域事件、識(shí)別限界上下文、識(shí)別問(wèn)題子域、聚合，再對(duì)聚合建模。并非解決數(shù)據(jù)查詢問(wèn)題、數(shù)據(jù)分析問(wèn)題。
前面我們了解了如何通過(guò)CQRS解決讀寫分離問(wèn)題，然而……
在實(shí)戰(zhàn)DDD過(guò)程中我們總會(huì)遇到一些即不適合領(lǐng)域建模也不能簡(jiǎn)單通過(guò)CQRS解決的問(wèn)題，如為前端提供住址、性別等選項(xiàng)的接口如何實(shí)現(xiàn)、用戶標(biāo)簽功能如何設(shè)計(jì)、評(píng)價(jià)功能如何設(shè)計(jì)……
對(duì)于這些看似簡(jiǎn)單的問(wèn)題，我們要考慮的是如何避免過(guò)度設(shè)計(jì)，保持架構(gòu)的簡(jiǎn)潔以及擴(kuò)展。
為前端提供選項(xiàng)有非常多的場(chǎng)景。有些選項(xiàng)是個(gè)枚舉類型，如性別、訂單類型;有些選項(xiàng)需要支持增加或刪除，如商品分類，雖然實(shí)體需要通過(guò)ID引用它，但卻又不適合作為實(shí)體存在。
無(wú)論是枚舉類型的選項(xiàng)，還是通過(guò)ID引用卻又不適合作為實(shí)體存在的選項(xiàng)，都應(yīng)該作為值對(duì)象?？梢灾苯釉趹?yīng)用層讀寫存儲(chǔ)/緩存中間件，如mysql、es、redis。
下文中會(huì)出現(xiàn)的領(lǐng)域(業(yè)務(wù))名詞：達(dá)人：網(wǎng)紅、紅人，有粉絲群體的個(gè)人、有一定影響力的個(gè)人;OTO探店：線上報(bào)名線下探店，線上推廣(主要服務(wù)美食點(diǎn)，為商家推廣線下店鋪);
我們項(xiàng)目中有需要實(shí)現(xiàn)為達(dá)人打標(biāo)簽的需求，在接到這個(gè)需求時(shí)，我們首先做的就是分析標(biāo)簽?zāi)墚a(chǎn)生什么樣的價(jià)值，再通過(guò)事件風(fēng)暴看是否能分析出領(lǐng)域事件。
結(jié)合項(xiàng)目業(yè)務(wù)分析，達(dá)人標(biāo)簽在我們項(xiàng)目中發(fā)揮的價(jià)值其實(shí)就是用于興趣匹配推送，在OTO探店業(yè)務(wù)場(chǎng)景下，興趣匹配可以理解為根據(jù)達(dá)人喜好的口味給達(dá)人推送相關(guān)店鋪的訂單。
分析到這里我們就清楚了標(biāo)簽功能要做的就是數(shù)據(jù)分析還有算法推薦，除此之外，標(biāo)簽沒(méi)有任何領(lǐng)域事件(行為、業(yè)務(wù)動(dòng)作)，標(biāo)簽不存在領(lǐng)域上下文，所以不應(yīng)該過(guò)度設(shè)計(jì)。
另外，為達(dá)人打標(biāo)簽/達(dá)人自己打標(biāo)簽，那么標(biāo)簽就是達(dá)人的值對(duì)象，與達(dá)人的性別、年齡、住址等屬性都是達(dá)人的值對(duì)象。達(dá)人可以添加標(biāo)簽或者刪除標(biāo)簽。
所以最終我們實(shí)現(xiàn)的標(biāo)簽功能就只是在達(dá)人的聚合根上添加一個(gè)標(biāo)簽值對(duì)象。給達(dá)人聚合根添加修改標(biāo)簽的方法。
另外我們需要為前端提供標(biāo)簽選項(xiàng)，支持管理員添加或刪除標(biāo)簽，與實(shí)現(xiàn)普通選項(xiàng)一樣，我們單獨(dú)在達(dá)人聚合下提供一個(gè)應(yīng)用層的LableService，直接操作數(shù)據(jù)庫(kù)增/刪標(biāo)簽。
標(biāo)簽表的存在只是提供標(biāo)簽選項(xiàng)，達(dá)人給自己打標(biāo)簽只能從系統(tǒng)提供的標(biāo)簽中選擇，標(biāo)簽相當(dāng)于只是選項(xiàng)。因此達(dá)人的標(biāo)簽值對(duì)象并非存標(biāo)簽的id，而是直接存標(biāo)簽的名稱。
當(dāng)標(biāo)簽選項(xiàng)刪除時(shí)我們不應(yīng)該為所有打了該標(biāo)簽的用戶默認(rèn)刪除他的標(biāo)簽，這實(shí)際是不允許的，就像我們不能隨便改用戶的性別、住址一樣。
只有在達(dá)人更新標(biāo)簽時(shí)不提供已經(jīng)刪除的選項(xiàng)，讓達(dá)人自己選擇新的標(biāo)簽更新，更新后舊的標(biāo)簽全部被替換也就達(dá)到刪除的目的。
除選項(xiàng)、標(biāo)簽外，我們要做的還有一個(gè)評(píng)價(jià)功能。
根據(jù)事件風(fēng)暴我們分析出以下領(lǐng)域事件： a、達(dá)人完成任務(wù)后商家可評(píng)價(jià)達(dá)人(每個(gè)任務(wù)只允許評(píng)價(jià)一次) b、商家評(píng)價(jià)達(dá)人后更新達(dá)人的得分(如內(nèi)容質(zhì)量得分) "商家評(píng)價(jià)達(dá)人"涉及到任務(wù)、達(dá)人、商家三個(gè)維度，達(dá)人可以查看商家給自己的評(píng)價(jià)，商家也可以查看自己給哪些達(dá)人寫了評(píng)價(jià)，并且都能查看任務(wù)關(guān)聯(lián)的評(píng)價(jià)。
顯然，無(wú)論是把評(píng)價(jià)功能放到任務(wù)上下文還是達(dá)人上下文、商家上下文，都不合理。因此我們?yōu)樵u(píng)價(jià)劃分出評(píng)價(jià)上下文，識(shí)別出評(píng)價(jià)問(wèn)題子域。 商家評(píng)價(jià)達(dá)人作為評(píng)價(jià)上下文的一個(gè)聚合，后期可能還會(huì)實(shí)現(xiàn)支持達(dá)人評(píng)價(jià)店鋪，而達(dá)人評(píng)價(jià)店鋪又是一個(gè)評(píng)價(jià)上下文的聚合，評(píng)價(jià)上下文存在多個(gè)聚合。
我們?cè)趯?shí)戰(zhàn)DDD過(guò)程中，在實(shí)現(xiàn)前端選項(xiàng)、標(biāo)簽功能、評(píng)價(jià)功能過(guò)程中也做了詳細(xì)的分析再設(shè)計(jì)，目的都是避免過(guò)度設(shè)計(jì)。
不斷摸索……
新聞標(biāo)題：DDD實(shí)戰(zhàn)中如何避免過(guò)度設(shè)計(jì)
網(wǎng)址分享：http://www.dlmjj.cn/article/dhscios.html
