如何在DDD中建立領(lǐng)域模型
作者 | TWInsights
在前文《??當(dāng)我們談?wù)揇DD時我們在談?wù)撌裁??》中我們討論了DDD的戰(zhàn)略設(shè)計和戰(zhàn)術(shù)設(shè)計。在本文中我們將繼續(xù)探討領(lǐng)域模型。
用領(lǐng)域模型表達(dá)領(lǐng)域概念
在實際項目中,模型設(shè)計者往往過早陷入具體構(gòu)造塊類型的識別,比如實體、聚合、領(lǐng)域服務(wù),而忽略了領(lǐng)域模型表達(dá)領(lǐng)域概念的目的。我們應(yīng)該基于領(lǐng)域概念設(shè)計領(lǐng)域模型,然后再采用合適的模式降低領(lǐng)域模型的復(fù)雜度,進(jìn)一步增加領(lǐng)域模型的表達(dá)能力。
領(lǐng)域模型的作用,一方面是關(guān)聯(lián)代碼實現(xiàn),一方面是關(guān)聯(lián)通用語言。我們對于模型和實現(xiàn)的關(guān)聯(lián)輕車熟路,但是對于語言和模型關(guān)聯(lián)往往有待提升。在溝通中刻意使用通用語言可以幫助我們驗證模型的合理性。
我們以一個題目為例,方便后續(xù)討論。
活動平臺提供用戶參與活動得到獎品的功能,吸引用戶及潛在用戶參與,以達(dá)到拉新、促活、引流的目的。
運營人員可以創(chuàng)建和修改活動,活動的配置內(nèi)容包括活動名稱、活動介紹、活動開放的開始時間和結(jié)束時間、參與資格、權(quán)益。
用戶可以看到活動列表,在活動開放的時間段內(nèi)進(jìn)入活動頁面看到活動介紹。用戶在活動頁面領(lǐng)取權(quán)益,經(jīng)判斷符合資格的用戶就會獲得一份獎品。權(quán)益可能是信用卡積分,也可能是優(yōu)惠券。
參與資格可能是:一天內(nèi)注冊的用戶、VIP用戶、當(dāng)月生日的用戶等??蛻粝M到y(tǒng)可以方便擴(kuò)展支持靈活的資格類型,以支持多樣的活動形式。
對于一個活動,一個用戶只能參加一次。
建立模型
第一步是根據(jù)需求分析模型。
我們可以找到以下概念:活動、參與資格、權(quán)益。其中參與資格是擴(kuò)展點。
對于需求「一個用戶只能參加一次活動的」,需要記錄用戶是否參與過活動,所以需要「活動參與記錄」的概念。
參與活動的結(jié)果可能有2種:符合參與資格則返回權(quán)益,不符合則返回「不符合」。所以我們用了Optional<權(quán)益>類型。
我們到這里只識別了各種名詞,需要走查用例,尋找缺失的概念:
- 用例1,運營人員可以創(chuàng)建并修改活動
- 用例2,用戶可以參與活動并獲得權(quán)益
對于用例1,創(chuàng)建和修改活動,目前模型已經(jīng)滿足了需求。
對于用例2,這里有一個模型之外的規(guī)則:「一個用戶只能參加一次活動」。這是所有活動都需要遵守的規(guī)則,我們將其稱為「活動通用規(guī)則」。
雖然只是一個很簡單的邏輯,但是提取「活動通用規(guī)則」這個概念非常有用。如果沒有這個概念,那么每次去描述這個概念,只能用「一個用戶只能參加一次活動的規(guī)則」去表示,非常繁瑣;也讓概念沒有安身之地,容易被隨便放到萬能的Service中。
我們將其加入領(lǐng)域模型。
我們沒有把「活動通用規(guī)則」放到活動概念里,一部分原因是這個判斷邏輯不需要具體活動的信息。
使用通用語言驗證模型
有了領(lǐng)域模型,就有了通用語言。使用通用語言重新描述需求,并盡量在溝通中使用通用語言。
運營人員可以創(chuàng)建和修改活動,活動的配置內(nèi)容包括活動名稱、活動介紹、活動開放的開始時間和結(jié)束時間時間段、參與資格、權(quán)益。
用戶可以看到活動列表,在活動開放的時間段內(nèi)進(jìn)入活動頁面看到活動介紹。用戶在活動頁面領(lǐng)取權(quán)益,經(jīng)判斷符合資格參與資格的用戶就會獲得一份獎品權(quán)益。權(quán)益可能是信用卡積分,也可能是優(yōu)惠券。
參與資格可能是:一天內(nèi)注冊的用戶、VIP用戶、當(dāng)月生日的用戶等??蛻粝M到y(tǒng)可以方便擴(kuò)展支持靈活的資格類型,以支持多樣的活動形式。
同時有「活動通用規(guī)則」:對于一個活動,一個用戶只能參加一次。
這里去掉了「開始時間」、「資格」、「獎品」等模糊不清晰的描述。使用基于領(lǐng)域模型的語言,讓需求描述清晰沒有歧義。
到目前為止,主要的領(lǐng)域模型都已經(jīng)分析出來。所有的模型都對應(yīng)明確的領(lǐng)域概念,不多也不少。
識別構(gòu)造塊類型
在分析了領(lǐng)域模型后,我們再來分析構(gòu)造塊類型。
我們通過是否有狀態(tài)來做區(qū)分。
首先識別有狀態(tài)的對象:活動、各種參與資格、權(quán)益、活動參與記錄、用戶。一般有狀態(tài)的對象都是事物,對應(yīng)的構(gòu)造塊類型也就是實體或者值對象。
其次判斷其狀態(tài)是否會改變:
- 活動會被修改,所以狀態(tài)會被改變;
- 參與資格會被修改,但是參與資格從屬于活動,修改后可以直接使用新的對象替換舊的,所以可以設(shè)計成狀態(tài)不變;
- 權(quán)益和參與資格一樣,也可以設(shè)計成狀態(tài)不變;
- 活動參與記錄,狀態(tài)可能發(fā)生變化;
- 用戶在這個模型中只是臨時存在,狀態(tài)不會變化。
狀態(tài)會改變的是實體,包括活動和活動參與記錄;狀態(tài)不變的就是值對象,包括參與資格、權(quán)益和用戶。
最后剩下的就是無狀態(tài)的對象:活動通用規(guī)則。對應(yīng)的構(gòu)造塊類型是領(lǐng)域服務(wù)。
這里的無狀態(tài)對象大都可以轉(zhuǎn)化成有狀態(tài)的對象,例如活動通用規(guī)則,可以將方法參數(shù)的Optional<活動參與記錄>變成成員變量。只是這里我們選擇了無狀態(tài)的設(shè)計方法。
由于領(lǐng)域服務(wù)沒有狀態(tài),所以可以在應(yīng)用啟動時就創(chuàng)建出來,也可以在使用時才創(chuàng)建。
經(jīng)過分析,我們的領(lǐng)域模型都有了類型。
設(shè)計聚合
首先識別生命周期長的領(lǐng)域?qū)ο螅涸谝粋€操作中被創(chuàng)建出來,操作結(jié)束后仍會被其他操作使用的對象。活動、參與資格、權(quán)益和活動參與記錄都是生命周期長的對象。
其他有狀態(tài)的對象都是臨時對象:在一個操作中被創(chuàng)建出來,操作結(jié)束后就不會再被使用。模型中的用戶,在一次操作中從其他服務(wù)獲取,使用后即被丟棄。
這里我們總結(jié)下各構(gòu)造塊類型的特點:
實體 | 值對象 | 領(lǐng)域服務(wù) | |
是否有狀態(tài) | 有且狀態(tài)可變 | 有且狀態(tài)不可變 | 無 |
生命周期 | 長 | 長或者短 | 長短均可 |
在生命周期的長的對象中,我們要設(shè)計聚合。聚合作為操作單元,主要解決以下幾個問題:
- 整個模型往往龐大復(fù)雜,為了降低知識負(fù)載,需要將其分解成多個小且簡單的模型,劃分清晰的邊界
- 部分模型對象之間存在一致性規(guī)則,例如需要被一起刪除,所以需要放在一個操作中
- 多個用戶可能會并發(fā)操作模型,為了避免相互干擾,需要讓操作單元盡可能小
- 對于操作單元,需要將其頻繁加載到內(nèi)存中,如果單元過大,往往不能滿足性能要求
根據(jù)對業(yè)務(wù)的了解,活動及參與資格、權(quán)益都是一起被創(chuàng)建和修改,可以放在一個聚合里;活動和活動參與記錄之間沒有一致性規(guī)則,可以分開;因為活動參與記錄數(shù)量會很多,如果和活動在一個聚合中,會降低性能。
所以我們將活動、參與資格、權(quán)益設(shè)計成一個聚合,而活動參與記錄作為一個單獨的聚合。而活動和活動參與記錄分別作為這兩個聚合的聚合根。對應(yīng)的,聚合都會配備其專屬的Repository。
同時加上遍歷方向箭頭。由于活動是聚合根,從活動可以遍歷到聚合內(nèi)部的參與資格和權(quán)益。另外查詢活動參與記錄,可以通過其Repository,所以沒有活動到活動參與記錄的箭頭。
由于我們將活動和活動參與記錄之間劃分成不同聚合,那他們之間的關(guān)聯(lián)將使用聚合的ID來關(guān)聯(lián),而不是聚合本身。
PS:如果使用了關(guān)聯(lián)對象,遍歷方向也可以是從活動到活動參與記錄。
如何使用領(lǐng)域模型
領(lǐng)域模型已經(jīng)建立完畢,我們來看如何使用領(lǐng)域模型以滿足用例。
運營人員創(chuàng)建活動基本信息及其關(guān)聯(lián)的參與資格和權(quán)益。領(lǐng)域模型的客戶(一般來說是應(yīng)用服務(wù)),使用運營人員輸入的參數(shù)構(gòu)造出活動對象,再利用Repository將其保存。
運營人員修改活動。應(yīng)用服務(wù)利用Repository獲取需要修改的活動,再根據(jù)運營人員提供的參數(shù)修改活動,最后利用Repository保存活動對象。
用戶參與活動。應(yīng)用服務(wù):
- 使用活動通用規(guī)則判斷用戶是否可以參加。由于活動通用規(guī)則需要用到活動參與記錄,因此應(yīng)用服務(wù)會使用Repository獲取活動參與記錄;
- 如果可以參加,則執(zhí)行活動的參與活動方法獲得結(jié)果。這需要利用Repository獲取用戶參與的活動,并構(gòu)造用戶對象(可能需要調(diào)用用戶服務(wù)獲取用戶信息,但是領(lǐng)域?qū)硬⒉魂P(guān)心這些邏輯);
- 如果結(jié)果是獲得權(quán)益,則創(chuàng)建活動參與記錄,并利用Repository保存。
考慮到并發(fā)情況,應(yīng)用服務(wù)可以在第1步前加鎖,并在第3步后釋放鎖。
再次思考
(1) 配置和參與活動可否是兩個模型?
在實現(xiàn)運營人員配置活動的用例過程中,我們會發(fā)現(xiàn)可能找到了一個隱藏的領(lǐng)域概念,將輸入的參數(shù)轉(zhuǎn)換成領(lǐng)域模型的邏輯有些枯燥和復(fù)雜,同樣將領(lǐng)域模型和數(shù)據(jù)庫的數(shù)據(jù)模型之間轉(zhuǎn)換也如此。輸入?yún)?shù)和數(shù)據(jù)模型都是只是扁平的數(shù)據(jù)數(shù)據(jù),沒有繼承結(jié)構(gòu)。如果使用另外一種面向數(shù)據(jù)的模型,也許這些用例實現(xiàn)起來會簡單得多。
每個模型都是為了解決某個問題。這里運營人員配置和用戶參與活動是不同的問題,如果用一個模型來解決這兩個問題,可能會有些吃力。那么干脆設(shè)計成兩個模型,使用限界上下文的概念將這兩個模型限定在各自的上下文中,也許更加合理。兩個模型可以共享同一份數(shù)據(jù)庫數(shù)據(jù),并加上一段(非領(lǐng)域?qū)拥模┻壿嬘糜谀P椭g的轉(zhuǎn)換。
這實際上是一種配置-使用模式。在配置階段,注重配置類型和參數(shù)、審批等;在使用階段,注重邏輯計算和性能。
(2) 活動參與記錄是否可以建模成領(lǐng)域事件?
活動參與記錄實際上是不可變的,可以將其設(shè)計為領(lǐng)域事件。
(3) 用戶參與活動的用例里,邏輯復(fù)雜,有泄漏領(lǐng)域概念的嫌疑?
如果發(fā)現(xiàn)應(yīng)用服務(wù)里邏輯變得復(fù)雜,可能意味著我們找到了一個隱藏的領(lǐng)域概念。我們可以定義一個「用戶參與活動邏輯」的概念:如果用戶通過了活動通用規(guī)則的判斷,則可以參與活動。將其加入模型和通用語言中,在溝通中驗證此概念是否合理。
總結(jié)
很多項目雖然也使用了以領(lǐng)域模型為中心的架構(gòu),但是設(shè)計者仍然是數(shù)據(jù)模型/貧血領(lǐng)域模型的思考方式,把大量領(lǐng)域邏輯放置在了萬能的Service中,讓領(lǐng)域概念隱藏在了冗長的過程代碼中,無法享受到DDD帶來的收益。
最后總結(jié)下本文想要強(qiáng)調(diào)的要點:
- 領(lǐng)域模型和領(lǐng)域概念一一對應(yīng)
- 領(lǐng)域模型和實現(xiàn)關(guān)聯(lián),也和通用語言關(guān)聯(lián)??桃馐褂猛ㄓ谜Z言溝通以驗證模型是否合理
- 演示了一種設(shè)計領(lǐng)域模型的步驟
- 構(gòu)造塊類型不是最重要的,領(lǐng)域模型本身更加重要
- 更多的使用可以表達(dá)業(yè)務(wù)含義的值對象和臨時值對象
- 聚合是一種設(shè)計,需要方法權(quán)衡
- 使用Repository、Factory獲取和創(chuàng)建領(lǐng)域模型是應(yīng)用層的職責(zé),領(lǐng)域?qū)討?yīng)該關(guān)注在表達(dá)領(lǐng)域概念