建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「Java藝術(shù)」，作者wujiuye。轉(zhuǎn)載本文請聯(lián)系Java藝術(shù)公眾號。
普陀網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站于2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。
DDD為什么難推行?因為我們習慣了舒適，并不是我們不想接受新事物，而是因為我們懶思考，習慣了以往一貫的流程開發(fā)、面向數(shù)據(jù)庫CRUD開發(fā)，很難轉(zhuǎn)換思維。
DDD要求我們根據(jù)產(chǎn)品原型建模，識別領(lǐng)域、限界上下文、子域，這些需要時間思考的問題就像一座座大山，讓我們望而卻步。且由于項目前期看不到DDD帶來的高效，反而沒那么敏捷了，并且前期的建模還可能要推倒重來，這讓更多人一開始就想放棄，而只有隨著需求的不斷迭代，DDD才會顯示出它的優(yōu)勢。
本篇筆者就以近期的一個項目跟大家分享筆者為該項目識別領(lǐng)域、限界上下文、子域，以及建模的過程。當然，分享的只是最初的一個版本。
領(lǐng)域通常指的就是業(yè)務(wù)范圍，每個公司都有自己明確的業(yè)務(wù)范圍。通常每個公司內(nèi)部都有很多個系統(tǒng)，如一家電商公司可能會有物流系統(tǒng)、電商系統(tǒng)、直播系統(tǒng)等等，每個系統(tǒng)做的事情則是更細分的領(lǐng)域。
茉莉紅交所項目是筆者入職茉莉數(shù)科集團后做的第一個項目，也是一個新的項目，由于沒有太多歷史包袱，筆者選擇從零開始搭建整個項目。并且由于初期業(yè)務(wù)簡單，所以才選擇在該項目試行DDD，寄希望于隨著業(yè)務(wù)的不斷迭代，能夠看到DDD發(fā)揮出的優(yōu)勢。
最初從產(chǎn)品那里了解到該項目要做的業(yè)務(wù)就是OTO(線上到線下)探店，那么OTO探店就是我們要了解的領(lǐng)域。
探店其實是達人幫助商家做推廣的一種有償活動，商家通過免費讓達人品嘗美食或是免門票游玩景點，達人最終通過短視頻、直播、圖文內(nèi)容等方式為商家做推廣。無論是探美食店、探游樂園，探店都是這個領(lǐng)域的核心。
在探店這個領(lǐng)域中，核心的業(yè)務(wù)名詞有：商家、達人、店鋪、訂單、任務(wù)。而行為有：商家發(fā)布探店訂單，訂單關(guān)聯(lián)店鋪，商家認證店鋪，達人接單(任務(wù))，商家發(fā)布訂單時通知達人，達人完成任務(wù)時通知商家。
現(xiàn)在，我們需要為業(yè)務(wù)劃分限界上下文。
限界上下文是業(yè)務(wù)概念的邊界，是業(yè)務(wù)問題最小粒度的劃分。在OTO探店業(yè)務(wù)領(lǐng)域中會包含多個限界上下文，我們通過找出這些確定的限界上下文對系統(tǒng)進行解耦，要求每一個限界上下文其內(nèi)部必須是緊密組織的、職責明確的、具有較高的內(nèi)聚性。
我們劃分出的限界上下文如下圖所示。
為什么將任務(wù)和訂單拆分為不同限界上下文(任務(wù)不是作為訂單聚合根的實體，而是作為一個獨立聚合的聚合根)?這是因為商家發(fā)布的一個訂單允許有不同的多個達人接單，一個達人也可以接不同商家的訂單，這并不是簡單的一對多關(guān)系。這更像是商品與訂單的關(guān)系，而不是訂單與訂單item的關(guān)系。
在劃分出限界上下文后，還需要根據(jù)限界上下文識別出問題子域。問題子域是對業(yè)務(wù)問題的劃分，相對限界上下文來說，是對業(yè)務(wù)問題更大粒度的劃分。
- 核心(子)域：產(chǎn)品的核心競爭力、盈利來源;
- 通用子域：常見的，不同領(lǐng)域都可共用的，可通過購買就能使用的;
- 支撐子域：非核心域、又非通用域，具有個性化需求，用于支撐核心域運作;
根據(jù)限界上下文，我們劃分出的子域如下圖所示。
OTO探店核心域：商家創(chuàng)建訂單、平臺對訂單審核，達人接單后生成任務(wù)、平臺對任務(wù)審核，達人完成任務(wù)回填內(nèi)容鏈接;
商家支撐子域：商家注冊、商家審核;
達人支撐子域：達人注冊、達人檔案管理、達人粉絲數(shù)據(jù)提取;
店鋪支撐子域：商家注冊店鋪、店鋪審核;(根據(jù)下版本的需求，將把店鋪當作商家聚合根的實體)
消息通知通用子域：短信通知、應用內(nèi)通知、小程序消息推送。
在劃分出子域后，我們就可以為領(lǐng)域建模了。
領(lǐng)域建模是通過將業(yè)務(wù)抽象為聚合、實體、聚合根、值對象模型的方式，封裝和承載全部的業(yè)務(wù)邏輯，保持業(yè)務(wù)的高內(nèi)聚和低耦合。
聚合：負責封裝業(yè)務(wù)邏輯，內(nèi)聚決策命令和領(lǐng)域事件，容納實體、聚合根、值對象。
- 聚合根：也是一種實體，是聚合的根節(jié)點，如訂單;
- 實體：聚合的主干，具有唯一標識和生命周期，如訂單Item;
- 值對象：實體的附加業(yè)務(wù)概念，用于描述實體所包含的業(yè)務(wù)信息，如訂單收件地址。
在技術(shù)實現(xiàn)上，一個聚合就是一個包，里面存放領(lǐng)域服務(wù)、工廠、資源庫、聚合根、實體、值對象。
領(lǐng)域?qū)影膭澐忠?guī)則通常為：
- --domain
- ----限界上下文
- ------聚合
- -------- （聚合根、值對象、實體、領(lǐng)域服務(wù)、資源庫、領(lǐng)域事件）
- ------聚合
- -------- （聚合根、值對象、實體、領(lǐng)域服務(wù)、資源庫、領(lǐng)域事件）
特別的，一個限界上下文可能包含多個聚合，但一個聚合只能存在于一個限界上下文。 如果一個限界上下文只有一個聚合，這種情況下我們通常省略限界上下文這一層。
以訂單限界上下文、任務(wù)限界上下文為例：
- --domain
- ----ordercontext
- ------orderType(訂單類型聚合（特殊的聚合，用于管理訂單分類）：美食（早餐/午餐/晚餐/下午茶）、...)
- ------order
- ----task
由于訂單存在兩個聚合，因此我們沒有省略訂單限界上下文這一層，而任務(wù)只有任務(wù)聚合，所以省略了任務(wù)限界上下文這一層。
以上包的劃分只是領(lǐng)域?qū)拥膭澐郑缶酆细?、值對象、實體、領(lǐng)域服務(wù)、資源庫、領(lǐng)域事件等類存放在聚合包下，無論是使用DDD經(jīng)典四層架構(gòu)，還是六邊形架構(gòu)。
我們并非采用DDD經(jīng)典四層架構(gòu)，也非六邊形架構(gòu)，我們實際對項目包的劃分如下。
當我們需要按限界上下文拆分訂單和任務(wù)為兩個微服務(wù)時，只需要copy一份項目代碼，一個項目中去掉ordercontext包，一個項目中去掉task包，并且將兩個限界上下文應用層之間的依賴調(diào)用改為通過遠程RPC調(diào)用。上圖中的xxxGateway類就是用于封裝遠程調(diào)用的，UserApplicationServiceGateway、RabbitmqConfiguration之所以放在最外層，因為兩個限界上下文都會用到。
以任務(wù)聚合為例，展開后的包結(jié)構(gòu)如下。
以上全部就是我們最初對OTO探店業(yè)務(wù)識別限界上下文、拆分子域、領(lǐng)域建模的過程，根據(jù)目前需求排期來看，這個模型我們即將要推倒重來一次，但對代碼的改動應該不大。
因為DDD缺少權(quán)威性的實踐指導和代碼約束，我們只能是通過實踐慢慢積累經(jīng)驗。
標題名稱：DDD項目實踐之領(lǐng)域、限界上下文、問題子域
本文來源：http://www.5511xx.com/article/coheheg.html
