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