DDD建模六個(gè)問(wèn)題與步驟是什么

1 六個(gè)問(wèn)題

1.1 為什么使用

DDD方法論的核心是將問(wèn)題不斷分解，把大問(wèn)題分解為小問(wèn)題，大業(yè)務(wù)分解小領(lǐng)域，簡(jiǎn)而言之就是分而治之，各個(gè)擊破。

分而治之是指直接面對(duì)大業(yè)務(wù)我們無(wú)從下手，需要按照一定方法進(jìn)行分解，分解為高內(nèi)聚的小領(lǐng)域，使得業(yè)務(wù)有邊界清晰，而這些小領(lǐng)域是我們有能力處理的，這就是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心。

各個(gè)擊破是指當(dāng)問(wèn)題被拆分為小領(lǐng)域后，因?yàn)樾☆I(lǐng)域業(yè)務(wù)內(nèi)聚，其子領(lǐng)域高度相關(guān)，我們?cè)诩夹g(shù)維度可以對(duì)其進(jìn)行詳細(xì)設(shè)計(jì)，在管理維度可以按照領(lǐng)域?qū)?xiàng)目進(jìn)行分工。需要指出DDD不能替代詳細(xì)設(shè)計(jì)，DDD是為了更清晰地進(jìn)詳細(xì)設(shè)計(jì)。

在微服務(wù)流行的互聯(lián)網(wǎng)行業(yè)，當(dāng)業(yè)務(wù)逐漸復(fù)雜時(shí)，技術(shù)人員需要解決如何劃分微服務(wù)邊界的問(wèn)題，DDD這種清晰化業(yè)務(wù)邊界的特性正好可以用來(lái)解決這個(gè)問(wèn)題。     

1.2 方法與目標(biāo)

我們的目標(biāo)是將業(yè)務(wù)劃分清晰的邊界，而DDD是達(dá)成目標(biāo)的有效方法之一，這一點(diǎn)是需要格外注意的。DDD是方法不是目標(biāo)，不需要為了使用而使用。例如業(yè)務(wù)模型比較簡(jiǎn)單可以很容易分析的業(yè)務(wù)就不需要使用DDD，還有一些目標(biāo)是快速驗(yàn)證類(lèi)型的項(xiàng)目，追求短平快，前期可能也不需要使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。     

1.3 整體與局部

領(lǐng)域可以劃分多個(gè)子領(lǐng)域，子域可以再劃分多個(gè)子子域，限界上下文本質(zhì)上也是一種子子域，那么在業(yè)務(wù)分解時(shí)一個(gè)業(yè)務(wù)模塊到底是領(lǐng)域、子域還是子子域？

我認(rèn)為不用糾結(jié)在這個(gè)問(wèn)題，因?yàn)檫@取決于看待這個(gè)模塊的角度。你認(rèn)為整體可能是別人的局部，你認(rèn)為的局部可能是別人的整體，叫什么名字不重要，最重要的是按照高內(nèi)聚的原則將業(yè)務(wù)高度相關(guān)的模塊收斂在一起。    

1.4 粒度粗與細(xì)

業(yè)務(wù)劃分粒度的粗細(xì)并沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)，還是要根據(jù)業(yè)務(wù)需要、開(kāi)發(fā)資源、技術(shù)實(shí)力等因素綜合考量。例如微服務(wù)拆分過(guò)細(xì)反而會(huì)增加開(kāi)發(fā)、部署和維護(hù)的復(fù)雜度，但是拆分過(guò)粗可能會(huì)導(dǎo)致大量業(yè)務(wù)高度耦合，開(kāi)發(fā)部署起來(lái)是挺快的，但是缺失可維護(hù)性和可擴(kuò)展性，這需要根據(jù)實(shí)際情況做出權(quán)衡。     

1.5 領(lǐng)域與數(shù)據(jù)

領(lǐng)域?qū)ο笈c數(shù)據(jù)對(duì)象一個(gè)重要的區(qū)別是值對(duì)象存儲(chǔ)方式。在討論領(lǐng)域?qū)ο蠛蛿?shù)據(jù)對(duì)象之前，我們首先討論實(shí)體和值對(duì)象這一組概念。實(shí)體是具有唯一標(biāo)識(shí)的對(duì)象，而唯一標(biāo)識(shí)會(huì)伴隨實(shí)體對(duì)象整個(gè)生命周期并且不可變更。值對(duì)象本質(zhì)上是屬性的集合，并沒(méi)有唯一標(biāo)識(shí)。

領(lǐng)域?qū)ο笤诎祵?duì)象的同時(shí)也保留了值對(duì)象的業(yè)務(wù)含義，而數(shù)據(jù)對(duì)象可以使用更加松散的結(jié)構(gòu)保存值對(duì)象，簡(jiǎn)化數(shù)據(jù)庫(kù)設(shè)計(jì)。

現(xiàn)在假設(shè)我們需要管理足球運(yùn)動(dòng)員信息，對(duì)應(yīng)的領(lǐng)域模型和數(shù)據(jù)模型應(yīng)該如何設(shè)計(jì)？姓名、身高、體重是一名運(yùn)動(dòng)員本質(zhì)屬性，加上唯一編號(hào)可以對(duì)應(yīng)實(shí)體對(duì)象。跑動(dòng)距離，傳球成功率，進(jìn)球數(shù)是運(yùn)動(dòng)員比賽中的表現(xiàn)，這些屬性的集合可以對(duì)應(yīng)值對(duì)象。

值對(duì)象在數(shù)據(jù)對(duì)象中可以用松散的數(shù)據(jù)結(jié)構(gòu)進(jìn)行存儲(chǔ)，而值對(duì)象在領(lǐng)域?qū)ο笾行枰Ａ羝錁I(yè)務(wù)含義如下圖所示：

我們根據(jù)圖示編寫(xiě)領(lǐng)域?qū)ο笈c數(shù)據(jù)對(duì)象代碼：

// 數(shù)據(jù)對(duì)象
public class FootballPlayerDO {
    private Long id;
    private String name;
    private Integer height;
    private Integer weight;
    private String gamePerformance;
}


// 領(lǐng)域?qū)ο?br/>public class FootballPlayerDMO {
    private Long id;
    private String name;
    private Integer height;
    private Integer weight;
    private GamePerformanceVO gamePerformanceVO;
}

public class GamePerformanceVO {
    private Double runDistance;
    private Double passSuccess;
    private Integer scoreNum;
}

1.6 抽象與實(shí)現(xiàn)

抽象的核心是找相同，對(duì)不同事物提取公因式。實(shí)現(xiàn)的核心是找不同，擴(kuò)展各自的屬性和特點(diǎn)。例如模板方法設(shè)計(jì)模式正是用抽象構(gòu)建框架，用實(shí)現(xiàn)擴(kuò)展細(xì)節(jié)。

我們?cè)倩氐綌?shù)據(jù)模型的討論，可以發(fā)現(xiàn)腳本化是一種拓展靈活性的方式，腳本化不僅指使用groovy、QLExpress腳本增強(qiáng)系統(tǒng)靈活性，還包括松散可擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)模型抽象出了姓名、身高、體重這些基本屬性，對(duì)于頻繁變化的比賽表現(xiàn)屬性，這些屬性值可能經(jīng)常變化，甚至屬性本身也是經(jīng)常變化，例如可能會(huì)加上射門(mén)次數(shù)，突破次數(shù)等，所以采用松散的JSON數(shù)據(jù)結(jié)構(gòu)進(jìn)行存儲(chǔ)。

2 六個(gè)步驟

工程理論總是要落地的，落地也是需要一些步驟和方法的。本文我們一起分析一個(gè)足球運(yùn)動(dòng)員信息管理系統(tǒng)，目標(biāo)是管理運(yùn)動(dòng)員從轉(zhuǎn)會(huì)到上場(chǎng)比賽整條鏈路信息，這個(gè)系統(tǒng)大家應(yīng)該也都沒(méi)有接觸過(guò)，我們一起來(lái)分析。需要說(shuō)明本實(shí)例著重演示DDD方法論如何落地，業(yè)務(wù)細(xì)節(jié)可能并不能面面俱到。

2.1 流程梳理

梳理流程有兩個(gè)問(wèn)題需要考慮，第一個(gè)問(wèn)題是從什么視角去梳理？因?yàn)椴煌娜丝吹降牧鞒淌遣灰粯拥摹４鸢甘侨Q于系統(tǒng)需要解決的是什么問(wèn)題，因?yàn)槲覀円芾磉\(yùn)動(dòng)員從轉(zhuǎn)會(huì)到上場(chǎng)比賽整條鏈路信息，所以從運(yùn)動(dòng)員視角出發(fā)是一個(gè)合適的選擇。

第二個(gè)問(wèn)題是對(duì)業(yè)務(wù)不熟悉怎么辦？因?yàn)槲覀儾皇求w育和運(yùn)動(dòng)專(zhuān)家，并不清楚整條鏈路的業(yè)務(wù)細(xì)節(jié)。答案是梳理流程時(shí)一定要有業(yè)務(wù)專(zhuān)家在場(chǎng)，因?yàn)闆](méi)有真實(shí)業(yè)務(wù)細(xì)節(jié)，無(wú)法領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。同理在互聯(lián)網(wǎng)梳理復(fù)雜業(yè)務(wù)流程時(shí)，一定要有對(duì)相關(guān)業(yè)務(wù)熟悉的產(chǎn)品經(jīng)理或者運(yùn)營(yíng)一起參與。

假設(shè)足球業(yè)務(wù)專(zhuān)家梳理出了業(yè)務(wù)流程，運(yùn)動(dòng)員提出轉(zhuǎn)會(huì)，協(xié)商一致后到新俱樂(lè)部體檢，體檢通過(guò)就進(jìn)行簽約。進(jìn)入新俱樂(lè)部后進(jìn)行訓(xùn)練，訓(xùn)練指標(biāo)達(dá)標(biāo)后上場(chǎng)比賽，賽后參加新聞發(fā)布會(huì)。

2.2 四色建模

(1) 時(shí)標(biāo)對(duì)象

四色建模第一種顏色是紅色，表示時(shí)標(biāo)對(duì)象。時(shí)標(biāo)對(duì)象是四色建模最重要的對(duì)象，可以理解為核心業(yè)務(wù)單據(jù)。在業(yè)務(wù)進(jìn)行過(guò)程中一定要對(duì)關(guān)鍵業(yè)務(wù)留下單據(jù)，通過(guò)這些單據(jù)可以追溯出整個(gè)業(yè)務(wù)流程。

時(shí)標(biāo)對(duì)象具有兩個(gè)特點(diǎn)：第一是事實(shí)不可變性，記錄了過(guò)去某個(gè)時(shí)間點(diǎn)或時(shí)間段內(nèi)發(fā)生的事實(shí)。第二是責(zé)任可追溯性，記錄了管理者關(guān)注的信息。現(xiàn)在我們分析本系統(tǒng)時(shí)標(biāo)對(duì)象有哪些，需要留下哪些核心業(yè)務(wù)單據(jù)。

轉(zhuǎn)會(huì)對(duì)應(yīng)轉(zhuǎn)會(huì)單據(jù)，體檢對(duì)應(yīng)體檢單據(jù)，簽合同對(duì)應(yīng)合同單據(jù)，訓(xùn)練對(duì)應(yīng)訓(xùn)練指標(biāo)單據(jù)，比賽對(duì)應(yīng)比賽指標(biāo)單據(jù)，新聞發(fā)布會(huì)對(duì)應(yīng)采訪(fǎng)單據(jù)。根據(jù)分析繪制如下時(shí)標(biāo)對(duì)象：

(2) 參與方、地、物

這三類(lèi)對(duì)象在四色建模中用綠色表示，我們以電商場(chǎng)景為例進(jìn)行說(shuō)明。用戶(hù)支付購(gòu)買(mǎi)商家的商品時(shí)，用戶(hù)和商家是參與方。物流系統(tǒng)發(fā)貨時(shí)配送單據(jù)需要有配送地址對(duì)象，地址對(duì)象就是地。訂單需要商品對(duì)象，物流配送需要有貨品，商品和貨品就是物。

我們分析本例可以知道參與方包含總經(jīng)理、隊(duì)醫(yī)、教練、球迷、記者，地包含訓(xùn)練地址、比賽地址、采訪(fǎng)地址，物包含簽名球衣和簽名足球：

(3) 角色對(duì)象

在四色建模中用黃色表示，這類(lèi)對(duì)象表示參與方、地、物是以什么角色參與到業(yè)務(wù)流程：

(4) 描述對(duì)象

我們可以為對(duì)象增加相關(guān)描述信息，在四色建模中用藍(lán)色表示：

2.3 劃分領(lǐng)域

在四色建模過(guò)程中我們體會(huì)到時(shí)標(biāo)對(duì)象是最重要的對(duì)象，因?yàn)槠涑休d了業(yè)務(wù)系統(tǒng)核心單據(jù)。在劃分領(lǐng)域時(shí)我們同樣離不開(kāi)時(shí)標(biāo)對(duì)象，通過(guò)收斂相關(guān)時(shí)標(biāo)對(duì)象劃分領(lǐng)域。

2.4 領(lǐng)域事件

當(dāng)業(yè)務(wù)系統(tǒng)發(fā)生一件事情時(shí)，如果本領(lǐng)域或其它領(lǐng)域有后續(xù)動(dòng)作跟進(jìn)，那么我們把這件事情稱(chēng)為領(lǐng)域事件，這個(gè)事件需要被感知。

例如球員比賽受傷了，這是比賽子域事件，但是醫(yī)療和訓(xùn)練子域是需要感知的，那么比賽子域就發(fā)出一個(gè)事件，醫(yī)療和訓(xùn)練子域會(huì)訂閱。

例如球員比賽取得進(jìn)球，這也是比賽子域事件，但是訓(xùn)練和合同子域也會(huì)關(guān)注這個(gè)事件，所以比賽子域也會(huì)發(fā)出一個(gè)比賽進(jìn)球事件，訓(xùn)練和合同子域會(huì)訂閱。

通過(guò)事件交互有一個(gè)問(wèn)題需要注意，通過(guò)事件訂閱實(shí)現(xiàn)業(yè)務(wù)只能采用最終一致性，需要放棄強(qiáng)一致性，這一點(diǎn)可能會(huì)引入新的復(fù)雜度需要權(quán)衡。

2.5 項(xiàng)目搭建

(1) API

接口層：提供面向外部接口聲明和DTO對(duì)象

(2) controller

訪(fǎng)問(wèn)層：提供HTTP訪(fǎng)問(wèn)入口

(3) service

業(yè)務(wù)層：領(lǐng)域?qū)雍蜆I(yè)務(wù)層都包含業(yè)務(wù)，但是用途不同。業(yè)務(wù)層可以組合不同領(lǐng)域業(yè)務(wù)，并且可以增加流控、監(jiān)控、日志、權(quán)限控制切面，相較于領(lǐng)域?qū)痈鼮樨S富，提供BO對(duì)象

(4) domain

領(lǐng)域?qū)樱禾峁〥MO（DomainObject）、VO、事件、數(shù)據(jù)訪(fǎng)問(wèn)對(duì)象，核心是按照領(lǐng)域進(jìn)行分包，領(lǐng)域內(nèi)高內(nèi)聚，領(lǐng)域間低耦合

(5) dependency

外部訪(fǎng)問(wèn)層：在這個(gè)模塊中調(diào)用外部RPC服務(wù)，解析返回碼和返回?cái)?shù)據(jù)

(6) infrastructure

基礎(chǔ)層：包含基礎(chǔ)功能，例如緩存工具，消息隊(duì)列，分布式鎖，消息發(fā)送等功能

我們展開(kāi)領(lǐng)域?qū)舆M(jìn)行分析。領(lǐng)域?qū)拥暮诵氖前凑疹I(lǐng)域進(jìn)行分包，并且提供DMO、VO、事件、數(shù)據(jù)訪(fǎng)問(wèn)對(duì)象，領(lǐng)域內(nèi)高內(nèi)聚，領(lǐng)域間低耦合，例如domain1對(duì)應(yīng)合同子域，domain2對(duì)應(yīng)訓(xùn)練子域，domain3對(duì)應(yīng)合同子域。

2.6 詳細(xì)設(shè)計(jì)

目前為止領(lǐng)域已經(jīng)確定了，現(xiàn)在可以根據(jù)領(lǐng)域劃分任務(wù)了，組內(nèi)成員分別負(fù)責(zé)一個(gè)或多個(gè)領(lǐng)域進(jìn)行詳細(xì)設(shè)計(jì)，這個(gè)階段就是大家非常熟悉的用例圖，活動(dòng)圖，時(shí)序圖，數(shù)據(jù)庫(kù)設(shè)計(jì)，接口設(shè)計(jì)的用武之地。需要說(shuō)明的是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)不是取代詳細(xì)設(shè)計(jì)，而是為了更清晰地詳細(xì)設(shè)計(jì)。