撥開迷霧，找回自我：DDD 應對具體業務場景，Domain Model 到底如何設計？

寫在前面

除了博文内容之外，和 netfocus 兄的讨論，也可以讓你學到很多（至少我是這樣），不要錯過哦。

撥開迷霧，找回自我：DDD 應對具體業務場景，Domain Model 到底如何設計？

　　閱讀目錄：

迷霧森林
找回自我
開源位址
後記

　　毫無疑問，領域驅動設計的核心是領域模型，領域模型的核心是實作業務邏輯，也就是說，在應對具體的業務場景的時候，實作業務邏輯是領域驅動設計最重要的一環，在寫這篇博文之前，先總結下之前關于 DDD（領域驅動設計）的三篇博文：

我的“第一次”，就這樣沒了：DDD（領域驅動設計）理論結合實踐：僞領域驅動設計，隻是用 .NET 實作的一個“空殼”，僅此而已。
一縷陽光：DDD（領域驅動設計）應對具體業務場景，如何聚焦 Domain Model（領域模型）？：隻是聚焦領域模型（認清各個部分的職責，讓設計的焦點集中在領域模型中），文中關于領域模型的實作就是一個“渣”，僅此而已。
死去活來，而不變質：Domain Model（領域模型）和 EntityFramework 如何正确進行對象關系映射？：走了個彎路，ORM 的映射關系及倉儲的實作，應該是在本篇内容之後探讨，原因都是腳本驅動模式惹的禍，如果說腳本驅動模式是惡魔（特定的環境，也有好處，不能一概而論，這邊隻是一個比喻），那領域驅動設計可以看作是天使，心裡想的是天使，卻聽了惡魔的話，為什麼？因為它在你心中已根深蒂固，僅此而已。

　　OO（面向對象）設計指導我們要面向（停頓一下）對象設計，也就是說你要去面向這個對象，去思考它的本質，說白了就是思考：它是從哪裡來，到哪裡去，生長軌迹，擁有的事物，自身的變化規律，現在的狀态等等方面，更深入一點就是站在哲學的角度去思考萬物的本質（請參考老子的道德經），咳咳，說大了。

　　但是，在現實生活中，我們是做軟體設計的程式員，需要做出東西給使用者用的，而不是像老子那樣逍遙的每天面對星空，去思考宇宙萬物（如果有興趣，你也可以試試，隻要不被你的女朋友罵死）。也就是說我們要面對具體的業務場景，而并非隻是單純的 OO，這就要求我們除了要 OO 之外，還要去探讨業務邏輯的本質以及實作。

　　以下内容是本人掉的一個又一個深坑，拼死爬了上來，在 DDD 的道路上，友情提醒各位：前方有坑，園友們請小心謹慎。

　　迷霧森林中，切勿迷失自我，不幸的是，我就這樣迷失了：

　　具體的業務場景還是短消息系統－MessageManager，存在 Message 和 User 兩個領域模型，業務邏輯：一個使用者給另一個使用者發送消息，就是這麼簡單，可以看作是一個最簡單的業務邏輯，當然在發送消息這個過程中會有其他的業務邏輯，先不探讨 Message 領域模型和 User 領域模型如何協調完成這個業務邏輯，我們先看以下，我在第一篇《我的“第一次”，就這樣沒了：DDD（領域驅動設計）理論結合實踐》博文中，關于領域模型的實作：

1 /**
 2 * author:xishaui
 3 * address:https://www.github.com/yuezhongxin/MessageManager
 4 **/
 5 
 6 using System;
 7 
 8 namespace MessageManager.Domain.DomainModel
 9 {
10     public class Message : IAggregateRoot
11     {
12         #region 構造方法
13         public Message()
14         {
15             this.ID = Guid.NewGuid().ToString();
16         }
17         #endregion
18 
19         #region 實體成員
20         public string FromUserID { get; set; }
21         public string FromUserName { get; set; }
22         public string ToUserID { get; set; }
23         public string ToUserName { get; set; }
24         public string Title { get; set; }
25         public string Content { get; set; }
26         public DateTime SendTime { get; set; }
27         public bool IsRead { get; set; }
28         public virtual User FromUser { get; set; }
29         public virtual User ToUser { get; set; }
30         #endregion
31 
32         #region IEntity成員
33         /// <summary>
34         /// 擷取或設定目前實體對象的全局唯一辨別。
35         /// </summary>
36         public string ID { get; set; }
37         #endregion
38     }
39 }

　　Are you kidding me？不，你沒看錯，以上就是 Message 領域模型的實作代碼，User 領域模型的代碼我就不貼了，比這個還要簡單，隻包含 ID 和 Name 兩個字段屬性，領域驅動設計主張的是充血模型，隻包含字段屬性的領域模型是極其貧血的，像上面的 Message 領域模型，充血的領域模型實作的是業務邏輯。上面我們說的發送消息這個業務邏輯，在領域模型中為什麼沒有展現？既然是基于領域驅動設計，那為什麼我還要這樣設計呢？這是為什麼呢？當時設計完之後，我也在思考這個問題，難道腦袋有問題？不可能吧？看下應用層的代碼就知道了：

1 /**
  2 * author:xishuai
  3 * address:https://www.github.com/yuezhongxin/MessageManager
  4 **/
  5 
  6 using AutoMapper;
  7 using MessageManager.Application.DTO;
  8 using MessageManager.Domain.DomainModel;
  9 using MessageManager.Domain.Repositories;
 10 using System.Collections.Generic;
 11 
 12 namespace MessageManager.Application.Implementation
 13 {
 14     /// <summary>
 15     /// Message管理應用層接口實作
 16     /// </summary>
 17     public class MessageServiceImpl : ApplicationService, IMessageService
 18     {
 19         #region Private Fields
 20         private readonly IMessageRepository messageRepository;
 21         private readonly IUserRepository userRepository;
 22         #endregion
 23 
 24         #region Ctor
 25         /// <summary>
 26         /// 初始化一個<c>MessageServiceImpl</c>類型的執行個體。
 27         /// </summary>
 28         /// <param name="context">用來初始化<c>MessageServiceImpl</c>類型的倉儲上下文執行個體。</param>
 29         /// <param name="messageRepository">“消息”倉儲執行個體。</param>
 30         /// <param name="userRepository">“使用者”倉儲執行個體。</param>
 31         public MessageServiceImpl(IRepositoryContext context,
 32             IMessageRepository messageRepository,
 33             IUserRepository userRepository)
 34             : base(context)
 35         {
 36             this.messageRepository = messageRepository;
 37             this.userRepository = userRepository;
 38         }
 39         #endregion
 40 
 41         #region IMessageService Members
 42         /// <summary>
 43         /// 通過發送方擷取消息清單
 44         /// </summary>
 45         /// <param name="userDTO">發送方</param>
 46         /// <returns>消息清單</returns>
 47         public IEnumerable<MessageDTO> GetMessagesBySendUser(UserDTO sendUserDTO)
 48         {
 49             //User user = userRepository.GetUserByName(sendUserDTO.Name);
 50             var messages = messageRepository.GetMessagesBySendUser(Mapper.Map<UserDTO, User>(sendUserDTO));
 51             if (messages == null)
 52                 return null;
 53             var ret = new List<MessageDTO>();
 54             foreach (var message in messages)
 55             {
 56                 ret.Add(Mapper.Map<Message, MessageDTO>(message));
 57             }
 58             return ret;
 59         }
 60         /// <summary>
 61         /// 通過接受方擷取消息清單
 62         /// </summary>
 63         /// <param name="userDTO">接受方</param>
 64         /// <returns>消息清單</returns>
 65         public IEnumerable<MessageDTO> GetMessagesByReceiveUser(UserDTO receiveUserDTO)
 66         {
 67             //User user = userRepository.GetUserByName(receiveUserDTO.Name);
 68             var messages = messageRepository.GetMessagesByReceiveUser(Mapper.Map<UserDTO, User>(receiveUserDTO));
 69             if (messages == null)
 70                 return null;
 71             var ret = new List<MessageDTO>();
 72             foreach (var message in messages)
 73             {
 74                 ret.Add(Mapper.Map<Message, MessageDTO>(message));
 75             }
 76             return ret;
 77         }
 78         /// <summary>
 79         /// 删除消息
 80         /// </summary>
 81         /// <param name="messageDTO"></param>
 82         /// <returns></returns>
 83         public bool DeleteMessage(MessageDTO messageDTO)
 84         {
 85             messageRepository.Remove(Mapper.Map<MessageDTO, Message>(messageDTO));
 86             return messageRepository.Context.Commit();
 87         }
 88         /// <summary>
 89         /// 發送消息
 90         /// </summary>
 91         /// <param name="messageDTO"></param>
 92         /// <returns></returns>
 93         public bool SendMessage(MessageDTO messageDTO)
 94         {
 95             Message message = Mapper.Map<MessageDTO, Message>(messageDTO);
 96             message.FromUserID = userRepository.GetUserByName(messageDTO.FromUserName).ID;
 97             message.ToUserID = userRepository.GetUserByName(messageDTO.ToUserName).ID;
 98             messageRepository.Add(message);
 99             return messageRepository.Context.Commit();
100         }
101         /// <summary>
102         /// 檢視消息
103         /// </summary>
104         /// <param name="ID"></param>
105         /// <returns></returns>
106         public MessageDTO ShowMessage(string ID, string isRead)
107         {
108             Message message = messageRepository.GetByKey(ID);
109             if (isRead == "1")
110             {
111                 message.IsRead = true;
112                 messageRepository.Update(message);
113                 messageRepository.Context.Commit();
114             }
115             return Mapper.Map<Message, MessageDTO>(message);
116         }
117         #endregion
118     }
119 }

　　可以看到應用層的代碼真是不忍直視，撇開其他操作，我們看下 SendMessage 這個方法，首先 MessageDTO 這個參數就不應該存在，下面用 AutoMapper 進行對象轉化，然後再進行指派操作，這個過程就是典型的過程思維模式，沒有展現出一點的 OO 思想，指派完之後，使用 Repository（倉儲）進行持久話，發送消息的這個業務邏輯展現在哪？如果硬要說展現的話，那就是：messageRepository.Add(message) 這段代碼了，想想當時無知的認為，發送消息的業務邏輯展現就是持久化資料庫，還真是可笑。

　　在這篇博文發表後，很多園友也都意識到了這個問題，什麼問題？主要是以下兩個：

Domain Model（領域模型）：領域模型到底該怎麼設計？你會看到，MessageManager 項目中的 User 和 Message 領域模型是非常貧血的，沒有包含任何的業務邏輯，現在網上很多關于 DDD 示例項目多數也存在這種情況，當然項目本身沒有業務，隻是簡單的“CURD”操作，但是如果是一些大型項目的複雜業務邏輯，該怎麼去實作？或者說，領域模型完成什麼樣的業務邏輯？什麼才是真正的業務邏輯？這個問題很重要，後續探讨。
Application（應用層）：應用層作為協調服務層，當遇到複雜性的業務邏輯時，到底如何實作，而不使其變成 BLL（業務邏輯層）？認清本質很重要，後續探讨。

　　簡而言之就是：領域模型太貧血；應用層變成了業務邏輯層。意識到問題，那就找問題所在，經過一番探查，把 Repository 作為了重點懷疑對象，為什麼？主要是我當時以為 Repository 的職責有問題，也就有了下面的這篇博文《一縷陽光：DDD（領域驅動設計）應對具體業務場景，如何聚焦 Domain Model（領域模型）？》，在這篇博文中，關于上面原因的分析，主要講到了以下兩個節點的内容：

Repository（倉儲）職責所在？
Domain Service（領域服務）的加入

　　雖然博文中也講到了領域模型的重新設計，但是設計之後還是一坨屎，這邊就不拿出來誤導大家了。回到上面的問題，關于 Repository 的職責問題，我當時是這樣分析的：

Repository 應用在應用層，這樣就緻使應用層和基礎層（我把資料持久化放在基礎層了）通信，忽略了最重要的領域層，領域層在其中起到的作用最多也就是傳遞一個非常貧血的領域模型，然後通過 Repository 進行“CRUD”，這樣的結果是，應用層不變成所謂的 BLL（常說的業務邏輯層）才怪，另外，因為業務邏輯都放在應用層了，領域模型也變得更加貧血。

　　乍一看，上面的分析還真沒什麼問題（看來我還是蠻會忽悠人的，嘿嘿），Repository 服務于領域，是以就必須把 Repository 的調用放在領域層中，領域模型又不能直接和 Repository 通信，是以我後來就把 Domain Service（領域服務）加了進來，讓領域服務和 Repository 進行協調，然後應用層和就和領域服務通信了，然後的然後。。。

　　有朋友看到這，會覺得沒錯啊，就是這樣啊（如果你也這樣認為，那我就去幹傳銷了），先不讨論對錯，我們看下領域服務究竟實作的是個什麼東西？領域模型變成了什麼？應用層又變成了什麼？