一、業(yè)務(wù)分析：統(tǒng)一語(yǔ)言與事件風(fēng)暴 1、統(tǒng)一語(yǔ)言：

客戶明白自己的領(lǐng)域知識(shí)也就是業(yè)務(wù)，以及自己需要解決的問(wèn)題，也叫做痛點(diǎn)，但是不知道技術(shù)。技術(shù)人員知道技術(shù)，但是不了解客戶的業(yè)務(wù)。所以兩者交流起來(lái)往往會(huì)有很多出入，技術(shù)人員和客戶交流的過(guò)程中要去不斷建立一種雙方都認(rèn)可的關(guān)鍵詞，來(lái)深化領(lǐng)域知識(shí)，使得領(lǐng)域模型的建立。

10年積累的成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有雙峰免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。2、事件風(fēng)暴：

一種基于工作坊的事件方法，它可以快速發(fā)現(xiàn)業(yè)務(wù)領(lǐng)域中正在發(fā)生的事件，知道領(lǐng)域建模及程序方法?；舅枷胧菍④浖_(kāi)發(fā)人員與領(lǐng)域?qū)＜遥蛻簦┰谝黄?，相互學(xué)習(xí)。讓領(lǐng)域?qū)＜腋永斫?/p>①領(lǐng)域事件：即領(lǐng)域中發(fā)生的事實(shí)（過(guò)去發(fā)生的事實(shí)）（fact）

在真實(shí)世界中，當(dāng)滿足某個(gè)條件的時(shí)候，某個(gè)發(fā)起者會(huì)觸發(fā)某個(gè)事件，做某件事情。

②事實(shí)（fact）：已經(jīng)發(fā)生，很重要

是指哪些過(guò)去已經(jīng)發(fā)生過(guò)的事件。
鑒于過(guò)去已經(jīng)發(fā)生的事件不會(huì)發(fā)生改變。
建設(shè)信息化系統(tǒng)的實(shí)質(zhì)就是：將過(guò)去已經(jīng)發(fā)生的事實(shí)，存儲(chǔ)到數(shù)據(jù)庫(kù)中。從而提高管理水平，效率。

③事件風(fēng)暴會(huì)議：

Ⅰ、目標(biāo)：以完成領(lǐng)域模型的創(chuàng)建
Ⅱ、參會(huì)人員：領(lǐng)域?qū)＜液蛙浖_(kāi)發(fā)人員
Ⅲ、會(huì)議以探討領(lǐng)域事件開(kāi)始，從前往后一次梳理，以確保領(lǐng)域中所有事件能夠覆蓋。
Ⅳ、項(xiàng)目組成語(yǔ)不斷增加各種命令和事件，進(jìn)而思考與之相關(guān)的資源，外部系統(tǒng)與時(shí)間。
Ⅴ、在分析過(guò)程中的人和事相互之間的關(guān)系以箭頭方式標(biāo)識(shí)，分析有沒(méi)有聚合關(guān)系，如果存在聚合關(guān)系，用紫色的便簽紙標(biāo)注出來(lái)。
Ⅵ、將模型分配到各個(gè)限界上下文中，構(gòu)建上下文地圖。

④案例：在線訂餐系統(tǒng)

Ⅰ、梳理流程，識(shí)別領(lǐng)域事件（當(dāng)達(dá)到某個(gè)條件，某個(gè)發(fā)起者發(fā)起某個(gè)事件）。

注意：領(lǐng)域事件是已經(jīng)發(fā)生，并且很重要（需要存儲(chǔ)到數(shù)據(jù)庫(kù)里）

疑問(wèn)：用戶選餐是不是一個(gè)領(lǐng)域事件呢？
是過(guò)去已經(jīng)發(fā)生的事情，重不重要呢？選餐本質(zhì)是個(gè)查詢操作，這些查詢的操作是不是一定要記錄下來(lái)呢？在很多系統(tǒng)是不需要記錄的。不考慮分析系統(tǒng)，對(duì)于業(yè)務(wù)系統(tǒng)來(lái)說(shuō)，選餐不是領(lǐng)域事件。

下單，接單，就緒，派送，送達(dá)需要記錄下來(lái)，存儲(chǔ)到數(shù)據(jù)庫(kù)中，因?yàn)橐呀?jīng)發(fā)生，所以命名是過(guò)去式。

Ⅱ、用每一個(gè)領(lǐng)域事件作為中心，分析和這件領(lǐng)域事件相關(guān)的人和事。

命令：藍(lán)色
和命令有關(guān)的人和事情：黃色便簽紙標(biāo)注
觸發(fā)者：標(biāo)注小人
箭頭：標(biāo)識(shí)有關(guān)系的人和事情，比如用戶下有地址。識(shí)別對(duì)象之間是否有聚合關(guān)系。
聚合：整體---->部分。例如，用戶有很多數(shù)據(jù)，地址是用戶的一些數(shù)據(jù),

如何識(shí)別聚合？
Ⅰ、整體與部分關(guān)系
Ⅱ、部分的生命周期在整體范圍內(nèi)，整體產(chǎn)生之前，部分不能產(chǎn)生。整體被刪除了，部分也要被刪除。

如果菜單是公用的，每個(gè)飯店都是引用菜單。一個(gè)飯店沒(méi)有的時(shí)候，菜單就有了。
如果每個(gè)飯店有各自的菜單，當(dāng)前飯店沒(méi)有的時(shí)候，這個(gè)飯店的菜單也沒(méi)有，所以就是是聚合。

Ⅲ、識(shí)別限界上下文

在我們整個(gè)項(xiàng)目里，有很多業(yè)務(wù)場(chǎng)景，在每次業(yè)務(wù)場(chǎng)景里，都有各自不同的領(lǐng)域?qū)ο?，在不同的領(lǐng)域?qū)ο笾g，會(huì)有各自密密麻麻的關(guān)系。那么現(xiàn)在是要繪制成一個(gè)個(gè)密密麻麻的大圖，還是按照業(yè)務(wù)場(chǎng)景繪制出一個(gè)個(gè)小圖呢？

限界上下文：業(yè)務(wù)場(chǎng)景就把系統(tǒng)劃分了很多部分，這些部分就成為了限界上下文。

各個(gè)限界上下文又不是相互孤立的，又有相互的聯(lián)系，相互之間的聯(lián)系就是上下文地圖。
通過(guò)限界上下文劃分微服務(wù)，上下文地圖就是各各微服務(wù)之間的接口。

在用戶下單的時(shí)候，需要用戶，用戶地址。用戶信息來(lái)自用戶注冊(cè)的上下文中。

Ⅳ、微服務(wù)的拆分

用戶和飯店是支持域，不管在用戶下單還是接單，派送的時(shí)候，都需要用到用戶和飯店的領(lǐng)域的，所以叫支持域名。

注意：DDD指導(dǎo)的是后端微服務(wù)。
前端的設(shè)計(jì)根據(jù)原型

Ⅴ、領(lǐng)域事件的通知：

push主動(dòng):上游做了事情以后，下游立馬響應(yīng)。比如上游下了單，下游立即接單。
pull被動(dòng)：掛號(hào)與接診。掛號(hào)暴露接口，醫(yī)生接診的時(shí)候調(diào)用掛號(hào)的接口。醫(yī)生什么時(shí)候需要接診的時(shí)候，接口查一下，所以下游不需要存一份 ?；颊邟焯?hào)以后，不需要立即通知，所以不需要

Ⅵ、對(duì)每一個(gè)領(lǐng)域事件，進(jìn)行領(lǐng)域建模，形成領(lǐng)域模型。

用戶下單領(lǐng)域模型：

壞處：每一次查詢訂單的時(shí)候都要調(diào)用用戶注冊(cè)的接口。
每次查詢菜品明細(xì)的時(shí)候需要菜單名稱
**
所以進(jìn)行一些調(diào)整：把用戶和用戶地址的一些信息冗余到訂單對(duì)象里，那么在查詢訂單的時(shí)候，就不需要再去訪問(wèn)用戶注冊(cè)服務(wù)，只有在查詢更詳細(xì)的信息的時(shí)候，再去遠(yuǎn)程調(diào)用。
(如果用戶基本信息那邊變了的話怎么辦呢)
**

飯店接單領(lǐng)域模型
因?yàn)椴捎昧送频姆绞?，所以，飯店接單這邊冗余了一份訂單對(duì)象

用戶訂的取消時(shí)間字段，飯店的訂單也要有取消時(shí)間，因?yàn)槿∠麜r(shí)間對(duì)于飯店業(yè)務(wù)是有用的。
用戶訂單的取消時(shí)間字段，對(duì)于騎手主題域的是沒(méi)有業(yè)務(wù)意義的，因?yàn)樵隍T士派送微服務(wù)是沒(méi)有操作的。

問(wèn)題：如果用戶接單的訂單發(fā)生了變更，飯店接單和騎士派送冗余的訂單需要修改么
思路：訂單在不同的主題域里不用完全保持一致，當(dāng)上游增加了一些字段的時(shí)候，對(duì)于下游，要看看這些增加的字段對(duì)我自己的業(yè)務(wù)有沒(méi)有意義。如果沒(méi)有意義，就不需要同步的修改，如果說(shuō)這些字段對(duì)我當(dāng)前主題域來(lái)說(shuō)很重要，要進(jìn)行業(yè)務(wù)的調(diào)整和業(yè)務(wù)的修改，那么需要同步的修改，進(jìn)行同步的操作。
目的：在每一次需求變更的時(shí)候，每一次修改的范圍盡量縮小。每來(lái)一個(gè)需求，更改一個(gè)微服務(wù)，但是這樣的情況不一定在所有的微服務(wù)都能保證，當(dāng)我們不能保證只改一個(gè)微服務(wù)的時(shí)候，我們的思路是盡量減少微服務(wù)修改的范圍。

二、領(lǐng)域?qū)ο舐涞氐匠绦蛟O(shè)計(jì)：落實(shí)到三種對(duì)象 1、服務(wù)Service：

領(lǐng)域建模中表示某些i行為或者操作。接受用戶的請(qǐng)求，執(zhí)行相應(yīng)的方法。數(shù)據(jù)在哪的？在實(shí)體和值對(duì)象中

2、實(shí)體Entity：

領(lǐng)域建模中標(biāo)識(shí)每一個(gè)業(yè)務(wù)個(gè)體的領(lǐng)域?qū)ο?。關(guān)注事物的每個(gè)個(gè)體。

3、值對(duì)象Value Object：

領(lǐng)域建模中標(biāo)識(shí)某個(gè)客觀事物的領(lǐng)域?qū)ο?。等于字典表。關(guān)注事物的類(lèi)型。
注意：不需要特別區(qū)分是是實(shí)體還是值對(duì)象，統(tǒng)一稱之為領(lǐng)域?qū)ο?，因?yàn)椴环智宄?duì)開(kāi)發(fā)影響也不大。

4、兩種設(shè)計(jì) ①貧血模型設(shè)計(jì)

下單：調(diào)用完訂單service下單，然后調(diào)用訂單dao，訂單明細(xì)dao。并且兩個(gè)dao在一個(gè)service里。并且要管緩存。 思考：訂單service滿足單一職責(zé)么？訂單管理dao,又要緩存，業(yè)務(wù)操作，不是單一職責(zé)的。 ②充血模型設(shè)計(jì)：service只負(fù)責(zé)業(yè)務(wù)操作，只負(fù)責(zé)save領(lǐng)域?qū)ο?，那么怎么save具體交給倉(cāng)庫(kù)。

注意:訂單service不能單獨(dú)操作訂單明細(xì)只能通過(guò)聚合根導(dǎo)航。只能操作整體不能操作部分。 5、聚合Aggregate：把整體和部分的關(guān)系，通過(guò)整體封裝起來(lái)，整體就是聚合根。

6、工廠：負(fù)責(zé)裝配，將訂單，訂單明細(xì)，用戶信息裝配。 7、倉(cāng)庫(kù)：類(lèi)似dao。同時(shí)要維護(hù)對(duì)象之間的關(guān)系。

三、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的使用范圍： 1、適用于：事務(wù)的增刪改，并且在增刪改的時(shí)候涉及到的查詢。 2、不適用，數(shù)據(jù)統(tǒng)計(jì)類(lèi)。比如統(tǒng)計(jì)所有的訂單明細(xì)預(yù)測(cè)趨勢(shì)。所以就不需要遵循領(lǐng)域驅(qū)動(dòng)了。 3、應(yīng)對(duì)方法：CQRS的引入，也就是查詢命令相分離。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級(jí)服務(wù)器適合批量采購(gòu)，新人活動(dòng)首月15元起，快前往官網(wǎng)查看詳情吧

本文題目：二、演練領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)過(guò)程-創(chuàng)新互聯(lián)
分享網(wǎng)址：http://chinadenli.net/article38/dgdgpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、云服務(wù)器、網(wǎng)站策劃、響應(yīng)式網(wǎng)站、定制網(wǎng)站、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)