DDD的庖丁解牛之道

1、DDD的庖丁解牛之道技術(shù)創(chuàng)新，變革未來21復(fù)雜性之源解決之道3案例分析復(fù)雜性之源你的“上帝”是怎么期望 的產(chǎn)品經(jīng)理是這么理解的設(shè)計師么是怎么設(shè)計的程序員們是這么開發(fā)的商業(yè)顧間是怎么形容的測試員們得到的它是怎么付諸于實際的客戶到底需要的是什么復(fù)雜性的源頭需求理解挑水功能人體系統(tǒng)挑水子系統(tǒng)砍柴子系統(tǒng)做飯子系統(tǒng)種地子系統(tǒng)種地功能砍柴功能做飯功能復(fù)雜性的源頭系統(tǒng)分析錯誤的抽象復(fù)雜性之源設(shè)計實現(xiàn)解決之道開發(fā)產(chǎn)品經(jīng)理表單 組件.轉(zhuǎn)賬 頭寸.經(jīng)過過濾和 翻譯轉(zhuǎn)換的 概念，存在 遺漏 曲解 并且難以察 覺，直到上 線才暴露一切不以統(tǒng)一語言為基礎(chǔ)的DDD都是偽DDD改善需求溝通統(tǒng)一語言實例需求表達(dá)：當(dāng)用戶驗證登

2、錄以后，顯示一個空的窗口當(dāng)玩家登錄以后，顯示一個空的游戲控制面板改善需求溝通統(tǒng)一語言實例命名風(fēng)格改善需求溝通統(tǒng)一語言實例代碼風(fēng)格改善需求溝通確保團(tuán)隊在所有交流活動和代碼中堅持使用統(tǒng)一語言在限界上下文中，保持語言的一致性（如口語、圖形（如UML圖等）、 文 字、代碼等）。統(tǒng)一語言貫穿千項目的各個環(huán)節(jié)User StoriesProject MeetingsTeam EmailsInstant MessagesSchedule PlanSoftware Documents改善需求溝通劃分限界上下文關(guān)注點分離從聚合出發(fā)： 一個聚合可能是最 小顆粒度的限界上下文考慮聚合之間的業(yè)務(wù)相關(guān)性，合并 高業(yè)務(wù)相關(guān)

3、性的聚合考慮限界上下文的概念完整性 合并業(yè)務(wù)價值不明確的限界上下文如果在不同限界上下文中看到了完全相同的實體，往往意味著模型是錯誤的。改善需求溝通強(qiáng)化系統(tǒng)分析沒有統(tǒng)一的數(shù)學(xué)表達(dá)式，很難想 象數(shù)學(xué)領(lǐng)域的發(fā)展用UML透視業(yè)務(wù)的多維度立體模型強(qiáng)化系統(tǒng)分析用四色原型進(jìn)一步分解業(yè)務(wù)模型強(qiáng)化系統(tǒng)分析傳統(tǒng)架構(gòu)將業(yè)務(wù)簡單切割成數(shù)據(jù)和行為，造成系統(tǒng)對業(yè)務(wù)問題的首肢 分離。一旦需求變更，影響的范圍邊界不清晰，使得維護(hù)成本很高。先苦后甜VS先甜后苦變革實現(xiàn)方法上升到對象層面是必然需求變化時：功能：最易變 數(shù)據(jù)：較易變 對象：最穩(wěn)定類屬性方法變革實現(xiàn)方法用較穩(wěn)定的把不穩(wěn)定的包起來變革設(shè)計思路DDD內(nèi)功心法 不是設(shè)計風(fēng)

4、格，也不是架構(gòu)模型，它是一種思想方法變革實現(xiàn)方法變革實現(xiàn)方法實踐案例解 牛 分 步 策 略第一步：領(lǐng)域劃分和限界上下文第二步：在事件風(fēng)暴中應(yīng)用統(tǒng)一語言第三步：用四色原型分析業(yè)務(wù)第四步：從分析模型到領(lǐng)域驅(qū)動設(shè)計第一步：領(lǐng)域劃分和限界上下文在線交易系統(tǒng)的領(lǐng)域劃分商 品財 務(wù)支 付安 全會 員物 流非業(yè)務(wù)獨立的非核心業(yè)務(wù)獨立的非核心業(yè)務(wù)核心核心域交易通用域支撐域庫存訂 單支付(g)安全(s)物流(g)交易(c)DUDDU訂單(s)DDU商品(s)DU U庫存(s)UDUU財務(wù)(g)DUU會員(s)UDDDU上下文與領(lǐng)域原則上一一對應(yīng)在線交易系統(tǒng)的限界上下文劃分上下文映射類型訂單(s)庫存(s)財務(wù)(

5、g)支付(g)安全(s)物流(g)U商品(s)UDD交易(c)DUUDDDU UUDUUDU會員(s)UDDDUC/SC/SC/SOHS+PLACLACLACLOnlineOHS+PLACLC/SACLC/SACLC/SC/SC/SACL上下文映射圖第二步：在事件風(fēng)暴中應(yīng)用統(tǒng)一語言概念：事件風(fēng)暴Event Storming是一種領(lǐng)域建模的實踐，最初由Alberto Brandolini 開發(fā)領(lǐng)域?qū)＜医榻B業(yè)務(wù)參與者可以任意提問參與者根據(jù)自己對業(yè)務(wù)的理解，將領(lǐng)域事件寫在橙色即時貼上每個即時貼一個事件事件采用xx已xx”的格式，如訂單已創(chuàng)建“從業(yè)務(wù)目標(biāo)出發(fā)，按時間順序?qū)ふ乙l(fā)的事件，表示法：XX已Y

6、Y。交易核心域的部分事件如下：訂單已創(chuàng)建訂單已支付倉儲已發(fā)貨訂單已簽收尋 找 事 件A已XXB已YY尋找引發(fā)領(lǐng)域事件的Command(決策）人的Command外部系統(tǒng)Command寸間規(guī)則Command尋找事件背后Command(決策）探索Command的產(chǎn)生、處理并生成領(lǐng) 域事件的過程Command的產(chǎn)生：誰？基于什么信息？發(fā)出了什么Command ？Command的處理： 系統(tǒng)根據(jù)什么信息處理Command？產(chǎn)生（更新）了 什么結(jié)果？生成了什么領(lǐng)域事件？1、客戶基于產(chǎn)品信息，發(fā)出了下單的Command類 同 于 用 例 回 合3、系統(tǒng)基于訂單己生成事件，產(chǎn)生了鎖定庫存Command5、第三

7、方支付基于客戶的訂單支付結(jié)果，產(chǎn)生了支付成功Command2、交易系統(tǒng)根據(jù)下單的Command和庫存的可售數(shù)額，產(chǎn)生了訂單，生成了訂單 己生成事件4、系統(tǒng)根據(jù)鎖定庫存Command ，更新了庫存的可售數(shù)額和已售未付款數(shù)額，生 成了庫存己鎖定事件6、系統(tǒng)根據(jù)支付成功Command ，產(chǎn)生了支付記錄，更新了訂單支付狀態(tài)，生成 了訂單己支付事件形成統(tǒng)一語言 庫存已鎖定庫存已扣減倉儲已配貨倉儲已發(fā)貨訂單已創(chuàng)建訂單已支付訂單已簽收下 單鎖 定 庫 存扣 減 庫 存支 付 成 功簽 收完 成 配 貨完 成 發(fā) 貨尋找更多Command和事件領(lǐng) 域 事 件將領(lǐng)域中發(fā)生的活動建模成一系列的離散事件，每個事件都

8、用領(lǐng) 域?qū)ο髞肀硎镜谌剑河盟纳头治鰳I(yè)務(wù)Part、Place、Thing:簡稱PPT，用淡綠色表示；Description:簡稱Desc，用淡藍(lán)色表示，主要用來 對PPT、ROLE和MI進(jìn)行描述。Role:用淡黃色表示，主要表示PPT在某個場景下扮 演的角色。MomentInterval:簡稱MI，用淡紅色表示，主要 表示在一刻或一段時間內(nèi)發(fā)生的一件事圃。MomentInteval Detail:簡稱MIDetail，用淡紅色 表示，主要表示MI的明細(xì)。四色是領(lǐng)域模型的元模型初步梳理對象之間的關(guān)系加深理解對象之間關(guān)系加入ROLE和DESC“逐步”建立有效的模型精煉領(lǐng)域模型交易系統(tǒng)分析模型（

9、部分）第四步：從分析模型到 領(lǐng)域驅(qū)動設(shè)計概念：聚合/聚合根/實體/值對象實體VS值對象值對像：地址、電話、 狀態(tài)、收貨人實體:買家、訂單條目值對象可以 跨聚合共享劃 分 聚 合分析模型的關(guān)聯(lián)不等于設(shè)計模型的關(guān)聯(lián)，設(shè)計模型可以實現(xiàn)為查詢降低實現(xiàn)模型的關(guān)聯(lián)數(shù)量聚合根之間不可直接引用分析模型不等于設(shè)計模型，但需要降低二者的表示差異性。從四色原型到DDD實現(xiàn)Part、Place、Thing:可以實現(xiàn)為DO或聚合根，也可實現(xiàn)為枚舉值成為VO;Description:可以實現(xiàn)為DO或聚合根，實現(xiàn)為枚舉類型可以成為VO。Role:如果Role有自己的狀態(tài)需要被記錄，可以實現(xiàn)為DO或聚合根，且推薦采 用關(guān)聯(lián)而不是繼承自PPT ;沒有狀態(tài)要被記錄，可以實現(xiàn)為有狀態(tài)領(lǐng)域服務(wù)。MomentInterval:可以實現(xiàn)為聚合根（記錄狀態(tài)）或領(lǐng)域服務(wù)（不記