日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
DDD項(xiàng)目實(shí)踐之領(lǐng)域、限界上下文、問題子域

 本文轉(zhuǎn)載自微信公眾號(hào)「Java藝術(shù)」，作者wujiuye。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java藝術(shù)公眾號(hào)。

普陀網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)建站于2013年創(chuàng)立到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

DDD為什么難推行?因?yàn)槲覀兞?xí)慣了舒適，并不是我們不想接受新事物，而是因?yàn)槲覀儜兴伎?，?xí)慣了以往一貫的流程開發(fā)、面向數(shù)據(jù)庫(kù)CRUD開發(fā)，很難轉(zhuǎn)換思維。

DDD要求我們根據(jù)產(chǎn)品原型建模，識(shí)別領(lǐng)域、限界上下文、子域，這些需要時(shí)間思考的問題就像一座座大山，讓我們望而卻步。且由于項(xiàng)目前期看不到DDD帶來的高效，反而沒那么敏捷了，并且前期的建模還可能要推倒重來，這讓更多人一開始就想放棄，而只有隨著需求的不斷迭代，DDD才會(huì)顯示出它的優(yōu)勢(shì)。

本篇筆者就以近期的一個(gè)項(xiàng)目跟大家分享筆者為該項(xiàng)目識(shí)別領(lǐng)域、限界上下文、子域，以及建模的過程。當(dāng)然，分享的只是最初的一個(gè)版本。

領(lǐng)域通常指的就是業(yè)務(wù)范圍，每個(gè)公司都有自己明確的業(yè)務(wù)范圍。通常每個(gè)公司內(nèi)部都有很多個(gè)系統(tǒng)，如一家電商公司可能會(huì)有物流系統(tǒng)、電商系統(tǒng)、直播系統(tǒng)等等，每個(gè)系統(tǒng)做的事情則是更細(xì)分的領(lǐng)域。

茉莉紅交所項(xiàng)目是筆者入職茉莉數(shù)科集團(tuán)后做的第一個(gè)項(xiàng)目，也是一個(gè)新的項(xiàng)目，由于沒有太多歷史包袱，筆者選擇從零開始搭建整個(gè)項(xiàng)目。并且由于初期業(yè)務(wù)簡(jiǎn)單，所以才選擇在該項(xiàng)目試行DDD，寄希望于隨著業(yè)務(wù)的不斷迭代，能夠看到DDD發(fā)揮出的優(yōu)勢(shì)。

最初從產(chǎn)品那里了解到該項(xiàng)目要做的業(yè)務(wù)就是OTO(線上到線下)探店，那么OTO探店就是我們要了解的領(lǐng)域。

探店其實(shí)是達(dá)人幫助商家做推廣的一種有償活動(dòng)，商家通過免費(fèi)讓達(dá)人品嘗美食或是免門票游玩景點(diǎn)，達(dá)人最終通過短視頻、直播、圖文內(nèi)容等方式為商家做推廣。無論是探美食店、探游樂園，探店都是這個(gè)領(lǐng)域的核心。

在探店這個(gè)領(lǐng)域中，核心的業(yè)務(wù)名詞有：商家、達(dá)人、店鋪、訂單、任務(wù)。而行為有：商家發(fā)布探店訂單，訂單關(guān)聯(lián)店鋪，商家認(rèn)證店鋪，達(dá)人接單(任務(wù))，商家發(fā)布訂單時(shí)通知達(dá)人，達(dá)人完成任務(wù)時(shí)通知商家。

現(xiàn)在，我們需要為業(yè)務(wù)劃分限界上下文。

限界上下文是業(yè)務(wù)概念的邊界，是業(yè)務(wù)問題最小粒度的劃分。在OTO探店業(yè)務(wù)領(lǐng)域中會(huì)包含多個(gè)限界上下文，我們通過找出這些確定的限界上下文對(duì)系統(tǒng)進(jìn)行解耦，要求每一個(gè)限界上下文其內(nèi)部必須是緊密組織的、職責(zé)明確的、具有較高的內(nèi)聚性。

我們劃分出的限界上下文如下圖所示。

為什么將任務(wù)和訂單拆分為不同限界上下文(任務(wù)不是作為訂單聚合根的實(shí)體，而是作為一個(gè)獨(dú)立聚合的聚合根)?這是因?yàn)樯碳野l(fā)布的一個(gè)訂單允許有不同的多個(gè)達(dá)人接單，一個(gè)達(dá)人也可以接不同商家的訂單，這并不是簡(jiǎn)單的一對(duì)多關(guān)系。這更像是商品與訂單的關(guān)系，而不是訂單與訂單item的關(guān)系。

在劃分出限界上下文后，還需要根據(jù)限界上下文識(shí)別出問題子域。問題子域是對(duì)業(yè)務(wù)問題的劃分，相對(duì)限界上下文來說，是對(duì)業(yè)務(wù)問題更大粒度的劃分。

  • 核心(子)域：產(chǎn)品的核心競(jìng)爭(zhēng)力、盈利來源;
  • 通用子域：常見的，不同領(lǐng)域都可共用的，可通過購(gòu)買就能使用的;
  • 支撐子域：非核心域、又非通用域，具有個(gè)性化需求，用于支撐核心域運(yùn)作;

根據(jù)限界上下文，我們劃分出的子域如下圖所示。

OTO探店核心域：商家創(chuàng)建訂單、平臺(tái)對(duì)訂單審核，達(dá)人接單后生成任務(wù)、平臺(tái)對(duì)任務(wù)審核，達(dá)人完成任務(wù)回填內(nèi)容鏈接;

商家支撐子域：商家注冊(cè)、商家審核;

達(dá)人支撐子域：達(dá)人注冊(cè)、達(dá)人檔案管理、達(dá)人粉絲數(shù)據(jù)提取;

店鋪支撐子域：商家注冊(cè)店鋪、店鋪審核;(根據(jù)下版本的需求，將把店鋪當(dāng)作商家聚合根的實(shí)體)

消息通知通用子域：短信通知、應(yīng)用內(nèi)通知、小程序消息推送。

在劃分出子域后，我們就可以為領(lǐng)域建模了。

領(lǐng)域建模是通過將業(yè)務(wù)抽象為聚合、實(shí)體、聚合根、值對(duì)象模型的方式，封裝和承載全部的業(yè)務(wù)邏輯，保持業(yè)務(wù)的高內(nèi)聚和低耦合。

聚合：負(fù)責(zé)封裝業(yè)務(wù)邏輯，內(nèi)聚決策命令和領(lǐng)域事件，容納實(shí)體、聚合根、值對(duì)象。

  • 聚合根：也是一種實(shí)體，是聚合的根節(jié)點(diǎn)，如訂單;
  • 實(shí)體：聚合的主干，具有唯一標(biāo)識(shí)和生命周期，如訂單Item;
  • 值對(duì)象：實(shí)體的附加業(yè)務(wù)概念，用于描述實(shí)體所包含的業(yè)務(wù)信息，如訂單收件地址。

在技術(shù)實(shí)現(xiàn)上，一個(gè)聚合就是一個(gè)包，里面存放領(lǐng)域服務(wù)、工廠、資源庫(kù)、聚合根、實(shí)體、值對(duì)象。

領(lǐng)域?qū)影膭澐忠?guī)則通常為：

 
 
 
 
    
  
  
  
  
  1. --domain 
    2. 
  
  
  
  
  2. ----限界上下文 
    3. 
  
  
  
  
  3. ------聚合 
    4. 
  
  
  
  
  4. -------- （聚合根、值對(duì)象、實(shí)體、領(lǐng)域服務(wù)、資源庫(kù)、領(lǐng)域事件） 
    5. 
  
  
  
  
  5. ------聚合 
    6. 
  
  
  
  
  6. -------- （聚合根、值對(duì)象、實(shí)體、領(lǐng)域服務(wù)、資源庫(kù)、領(lǐng)域事件） 
    7.

特別的，一個(gè)限界上下文可能包含多個(gè)聚合，但一個(gè)聚合只能存在于一個(gè)限界上下文。 如果一個(gè)限界上下文只有一個(gè)聚合，這種情況下我們通常省略限界上下文這一層。

以訂單限界上下文、任務(wù)限界上下文為例：

 
 
 
 
    
  
  
  
  
  1. --domain 
    2. 
  
  
  
  
  2. ----ordercontext 
    3. 
  
  
  
  
  3. ------orderType(訂單類型聚合（特殊的聚合，用于管理訂單分類）：美食（早餐/午餐/晚餐/下午茶）、...) 
    4. 
  
  
  
  
  4. ------order 
    5. 
  
  
  
  
  5. ----task 
    6.

由于訂單存在兩個(gè)聚合，因此我們沒有省略訂單限界上下文這一層，而任務(wù)只有任務(wù)聚合，所以省略了任務(wù)限界上下文這一層。

以上包的劃分只是領(lǐng)域?qū)拥膭澐?，要求聚合根、值?duì)象、實(shí)體、領(lǐng)域服務(wù)、資源庫(kù)、領(lǐng)域事件等類存放在聚合包下，無論是使用DDD經(jīng)典四層架構(gòu)，還是六邊形架構(gòu)。

我們并非采用DDD經(jīng)典四層架構(gòu)，也非六邊形架構(gòu)，我們實(shí)際對(duì)項(xiàng)目包的劃分如下。

當(dāng)我們需要按限界上下文拆分訂單和任務(wù)為兩個(gè)微服務(wù)時(shí)，只需要copy一份項(xiàng)目代碼，一個(gè)項(xiàng)目中去掉ordercontext包，一個(gè)項(xiàng)目中去掉task包，并且將兩個(gè)限界上下文應(yīng)用層之間的依賴調(diào)用改為通過遠(yuǎn)程RPC調(diào)用。上圖中的xxxGateway類就是用于封裝遠(yuǎn)程調(diào)用的，UserApplicationServiceGateway、RabbitmqConfiguration之所以放在最外層，因?yàn)閮蓚€(gè)限界上下文都會(huì)用到。

以任務(wù)聚合為例，展開后的包結(jié)構(gòu)如下。

以上全部就是我們最初對(duì)OTO探店業(yè)務(wù)識(shí)別限界上下文、拆分子域、領(lǐng)域建模的過程，根據(jù)目前需求排期來看，這個(gè)模型我們即將要推倒重來一次，但對(duì)代碼的改動(dòng)應(yīng)該不大。

因?yàn)镈DD缺少權(quán)威性的實(shí)踐指導(dǎo)和代碼約束，我們只能是通過實(shí)踐慢慢積累經(jīng)驗(yàn)。


標(biāo)題名稱：DDD項(xiàng)目實(shí)踐之領(lǐng)域、限界上下文、問題子域
文章來源：http://m.5511xx.com/article/coheheg.html