首页 > 代码库 > 拨开迷雾，找回自我：DDD（领域驱动设计）应对具体业务场景，Domain Model（领域模型）到底如何设计？
拨开迷雾，找回自我：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 : IAggregateRoot11 {12 #region 构造方法13 public Message()14 {15 this.ID = Guid.NewGuid().ToString();16 }17 #endregion18 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 #endregion31 32 #region IEntity成员33 /// <summary>34 /// 获取或设置当前实体对象的全局唯一标识。35 /// </summary>36 public string ID { get; set; }37 #endregion38 }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 #endregion118 }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 进行协调，然后应用层和就和领域服务通信了，然后的然后。。。
有朋友看到这，会觉得没错啊，就是这样啊（如果你也这样认为，那我就去干传销了），先不讨论对错，我们看下领域服务究竟实现的是个什么东西？领域模型变成了什么？应用层又变成了什么？
领域服务代码：
1 /** 2 * author:xishuai 3 * address:https://www.github.com/yuezhongxin/MessageManager 4 **/ 5 6 using MessageManager.Domain.DomainModel; 7 using MessageManager.Domain.Repositories; 8 using System.Collections.Generic; 9 10 namespace MessageManager.Domain.DomainService11 {12 /// <summary>13 /// Message领域服务实现14 /// </summary>15 public class MessageDomainService : IMessageDomainService16 {17 #region Private Fields18 private readonly IMessageRepository messageRepository;19 private readonly IUserRepository userRepository;20 #endregion21 22 #region Ctor23 public MessageDomainService(IMessageRepository messageRepository, IUserRepository userRepository)24 {25 this.messageRepository = messageRepository;26 this.userRepository = userRepository;27 }28 #endregion29 30 #region IMessageDomainService Members31 public bool DeleteMessage(Message message)32 {33 messageRepository.Remove(message);34 return messageRepository.Context.Commit();35 }36 public bool SendMessage(Message message)37 {38 message.LoadUserName(userRepository.GetUser(new User { Name = message.FromUserName })39 , userRepository.GetUser(new User { Name = message.ToUserName }));40 messageRepository.Add(message);41 return messageRepository.Context.Commit();42 }43 public Message ShowMessage(string id, User currentUser)44 {45 Message message = messageRepository.GetByKey(id);46 message.ReadMessage(userRepository.GetUser(new User { Name = currentUser.Name }));47 messageRepository.Update(message);48 messageRepository.Context.Commit();49 return message;50 }51 public IEnumerable<Message> GetMessagesBySendUser(User user)52 {53 User userResult = userRepository.GetUser(user);54 return messageRepository.GetMessagesBySendUser(userResult);55 }56 public IEnumerable<Message> GetMessagesByReceiveUser(User user)57 {58 User userResult = userRepository.GetUser(user);59 return messageRepository.GetMessagesByReceiveUser(userResult);60 }61 public int GetNoReadCount(User user)62 {63 User userResult = userRepository.GetUser(user);64 return messageRepository.GetNoReadCount(userResult);65 }66 #endregion67 }68 }
应用层代码：
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.DomainService; 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 IMessageDomainService messageService; 21 #endregion 22 23 #region Ctor 24 /// <summary> 25 /// 初始化一个<c>MessageServiceImpl</c>类型的实例。 26 /// </summary> 27 /// <param name="messageRepository">“消息”服务实例。</param> 28 public MessageServiceImpl(IMessageDomainService messageService) 29 { 30 this.messageService = messageService; 31 } 32 #endregion 33 34 #region IMessageService Members 35 /// <summary> 36 /// 通过发送方获取消息列表 37 /// </summary> 38 /// <param name="userDTO">发送方</param> 39 /// <returns>消息列表</returns> 40 public IEnumerable<MessageDTO> GetMessagesBySendUser(UserDTO sendUserDTO) 41 { 42 //User user = userRepository.GetUserByName(sendUserDTO.Name); 43 var messages = messageService.GetMessagesBySendUser(Mapper.Map<UserDTO, User>(sendUserDTO)); 44 if (messages == null) 45 return null; 46 var ret = new List<MessageDTO>(); 47 foreach (var message in messages) 48 { 49 ret.Add(Mapper.Map<Message, MessageDTO>(message)); 50 } 51 return ret; 52 } 53 /// <summary> 54 /// 通过接受方获取消息列表 55 /// </summary> 56 /// <param name="userDTO">接受方</param> 57 /// <returns>消息列表</returns> 58 public IEnumerable<MessageDTO> GetMessagesByReceiveUser(UserDTO receiveUserDTO) 59 { 60 //User user = userRepository.GetUserByName(receiveUserDTO.Name); 61 var messages = messageService.GetMessagesByReceiveUser(Mapper.Map<UserDTO, User>(receiveUserDTO)); 62 if (messages == null) 63 return null; 64 var ret = new List<MessageDTO>(); 65 foreach (var message in messages) 66 { 67 ret.Add(Mapper.Map<Message, MessageDTO>(message)); 68 } 69 return ret; 70 } 71 /// <summary> 72 /// 删除消息 73 /// </summary> 74 /// <param name="messageDTO"></param> 75 /// <returns></returns> 76 public bool DeleteMessage(MessageDTO messageDTO) 77 { 78 return messageService.DeleteMessage(Mapper.Map<MessageDTO, Message>(messageDTO)); 79 } 80 /// <summary> 81 /// 发送消息 82 /// </summary> 83 /// <param name="messageDTO"></param> 84 /// <returns></returns> 85 public bool SendMessage(MessageDTO messageDTO) 86 { 87 return messageService.SendMessage(Mapper.Map<MessageDTO, Message>(messageDTO)); 88 } 89 /// <summary> 90 /// 查看消息 91 /// </summary> 92 /// <param name="ID"></param> 93 /// <returns></returns> 94 public MessageDTO ShowMessage(string id, UserDTO currentUserDTO) 95 { 96 Message message = messageService.ShowMessage(id, Mapper.Map<UserDTO, User>(currentUserDTO)); 97 return Mapper.Map<Message, MessageDTO>(message); 98 } 99 /// <summary>100 /// 获取未读消息数101 /// </summary>102 /// <param name="user"></param>103 /// <returns></returns>104 public int GetNoReadCount(UserDTO userDTO)105 {106 return messageService.GetNoReadCount(Mapper.Map<UserDTO, User>(userDTO));107 }108 #endregion109 }110 }
领域模型代码：
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 : IAggregateRoot11 {12 #region 构造方法13 public Message()14 {15 this.ID = Guid.NewGuid().ToString();16 }17 #endregion18 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 #endregion31 32 #region 业务逻辑33 /// <summary>34 /// 阅读消息35 /// </summary>36 /// <param name="CurrentUser"></param>37 public void ReadMessage(User currentUser)38 {39 if (!this.IsRead && currentUser.ID.Equals(ToUserID))40 {41 this.IsRead = true;42 }43 }44 /// <summary>45 /// 加载用户46 /// </summary>47 /// <param name="sendUser"></param>48 /// <param name="receiveUser"></param>49 public void LoadUserName(User sendUser, User receiveUser)50 {51 this.FromUserID = sendUser.ID;52 this.ToUserID = receiveUser.ID;53 }54 #endregion55 56 #region IEntity成员57 /// <summary>58 /// 获取或设置当前实体对象的全局唯一标识。59 /// </summary>60 public string ID { get; set; }61 #endregion62 }63 }
其实上面代码，如果是 DDD 大神来看的话，他只要看领域模型中的代码就行了，因为领域驱动设计的核心就是领域模型，那领域模型变成了什么？只是添加了 ReadMessage 和 LoadUserName 两个不是业务逻辑的业务逻辑方法（因为只有他们两个，如果把他们两个去掉，就变回原来的贫血模型了，所以，你懂的），领域服务中的 SendMessage 方法变的和原来的应用层代码一样，要说变化的话，只是把 Application 单词变成了 Domain Service 这个单词，其他无任何变化，应用层的代码也就变成了下面这样：
1 /// <summary>2 /// 发送消息3 /// </summary>4 /// <param name="messageDTO"></param>5 /// <returns></returns>6 public bool SendMessage(MessageDTO messageDTO)7 {8 return messageService.SendMessage(Mapper.Map<MessageDTO, Message>(messageDTO));9 }
在领域驱动设计中，应用层的定义是很薄的一层，可以看到，上面的应用层代码也未免太薄了吧，为什么？因为原来它的工作让领域服务做了，导致现在变成了一个调用外壳（也就是可有可无的东西，没有任何意义）。
》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》分割线《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《
为什么会有分割线？因为在应对具体业务场景中，上面做的操作都是无用功，为什么？因为设计的领域模型中什么东西都没有（指的是业务逻辑），没有任何东西的领域模型，还是真正的领域驱动设计吗？关于这个问题，傻子都知道，当然我也不傻，嘿嘿。
认识到这个根本问题后，下面就抛开一切外在因素，比如领域服务、仓储、应用层、表现层等等，这些统统不管，只做领域模型的设计，让真正的设计焦点集中在领域模型上，然后再针对领域模型做单元测试。
对，就是这么简单，至少听起来的确简单，事实真是这样吗？我却不这样认为，因为就是这个简单的问题，我为此痛苦了两三天的时间，说夸张点就是：吃不下饭，睡不着觉，在这个过程中，领域模型的一行代码我也没有写，不是不想写，而是不知道如何写？这是最最痛苦的，真是体会到了才知道。写不出来怎么办？我就找遍网上所有关于领域模型设计的资料（大部分都是英文，只能很痛苦的看），还有《领域驱动设计》和《企业应用架构模式》这两本书，希望能从中找到些灵感（就像画画，难点就在如何画第一笔），并不是模仿，这个也模仿不来，因为每个业务场景都不相同，遗憾的是没有找到任何的灵感，唯一找到的线索就是 OO 设计（大家都知道，我却不知道，因为蒙了）。
既然是要面向对象，那就分析一下对象，主要包含两个：用户和消息。对象拥有自身的属性、状态和行为，发送消息是用户的一种行为，所以发送消息这个操作应该放在用户中，那现在消息只有自身的一些属性值，因为在面向对象中，它是固定的，只有通过用户来调用它，用户领域模型代码如下：
1 /** 2 * author:xishaui 3 * address:https://www.github.com/yuezhongxin/MessageManager 4 **/ 5 6 using MessageManager.Domain.Demo.V1.Event; 7 using System; 8 using System.Collections.Generic; 9 10 namespace MessageManager.Domain.Demo.V111 {12 public class User13 {14 public User()15 {16 this.ID = Guid.NewGuid().ToString();17 }18 19 public string ID { get; set; }20 public string Name { get; set; }21 public virtual ICollection<Message> SendMessages { get; set; }22 public virtual ICollection<Message> ReceiveMessages { get; set; }23 24 public void SendMessage(Message message)25 {26 User toUser = GetUser(message.ToUser);27 if (toUser == null)28 {29 throw new NotImplementedException();30 }31 message.FromUser = this;32 message.ToUser = toUser;33 this.SendMessages.Add(message);34 toUser.ReceiveMessages.Add(message);35 DomainEvents.Raise(new MessageEvent() { DoMessage = message });36 ///37 }38 }39 }
按照面向对象设计，消息是用户的附属对象，只有用户存在，消息才有意义，一个用户对象拥有多个消息的对象集合，那怎么体现出发送消息这个动作呢？答案就是：this.SendMessages.Add(message) 这段代码，表示往用户对象的消息集合填充消息对象，这样就会相对于用户对象来说，这条消息的发送动作就完成了。先不考虑这样设计的合理或者不合理，我们看下消息模型中的代码，就会发现里面只有一些字段属性，没有任何的操作，还有就是如果我们要添加消息的其他动作，比如查找，删除等等，按照上面的分析，我们就会在用户对象中添加这些操作，因为这些动作都是用户所具有的，合理吗？至少听起来就不合理。
身处这个迷雾森林，才知道它的恐怖之处，不断的迷失自我，以致最后可能连自己都不相信，并怀疑自己。
找回自我
在迷雾森林之中，如何找回自我？而不迷失，没有确切的答案，我只能寻觅那一缕阳光一步一步的往前行。。。
首先，Repository，和你说声抱歉，非常抱歉，让你蒙冤，是我误会你了，因为我对业务逻辑的不理解，以致做出错误的做法。
回到短消息系统－MessageManager，需要注意的是，我们做的是消息系统，一切的一切都应该围绕 Message 领域模型展开，在这个系统中，最重要的就是发送消息这个业务逻辑，什么叫发消息？不要被上面的面向对象所迷惑，只考虑发消息这个具体的业务，我们来分析一下：比如在现实生活中，我们要给女朋友写信，首先我们要写信的内容，写完之后，要写一下女朋友的地址信息及名字，这个写信才算完成，邮递员邮递并不在这个业务逻辑之内了，因为这封信我写上收件人之后，这封信相对于我来说就已经发出了，后面只不过是收件人收不收得到的问题了（即使我写好，没有寄出去）。也就是说邮递员邮递这个工作过程相当于数据的持久化，写信的这个过程就是邮递（发消息的业务逻辑），just it。
理解上面的内容很重要，然后我们再来看 Message 这个领域模型，创建这个对象的时候，就说明我们已经把消息的内容写好了，也就是必要的东西，比如：消息标题、消息内容、发送人、发送时间等等，用代码实现就是在 Message 领域模型中的构造函数传递必要值，代码如下：
1 /** 2 * author:xishuai 3 * address:https://www.github.com/yuezhongxin/MessageManager 4 **/ 5 6 using System; 7 8 namespace MessageManager.Domain.DomainModel 9 {10 public class Message : IAggregateRoot11 {12 public Message(string title, string content, User sendUser)13 {14 if (title.Equals("") || content.Equals("") || sendUser == null)15 {16 throw new ArgumentNullException();17 }18 this.ID = Guid.NewGuid().ToString();19 this.Title = title;20 this.Content = content;21 this.SendTime = DateTime.Now;22 this.State = MessageState.NoRead;23 this.SendUser = sendUser;24 }25 public string ID { get; set; }26 public string Title { get; set; }27 public string Content { get; set; }28 public DateTime SendTime { get; set; }29 public MessageState State { get; set; }30 public virtual User SendUser { get; set; }31 public virtual User ReceiveUser { get; set; }32 33 public bool Send(User receiveUser)34 {35 if (receiveUser == null)36 {37 throw new ArgumentNullException();38 }39 this.ReceiveUser = receiveUser;40 return true;41 ///to do...42 }43 }44 }
在实例 Message 领域模型之前要对必要值进行判断，发送消息的关键代码就是：ReceiveUser = receiveUser，表示为这条消息“贴上”收件人的标签，指示这条消息的发送动作已经完成，当然在这个 Send 业务方法中可能还会有其他业务逻辑的加入，其实发送消息就是这样，在 Message 这个领域模型中，没有什么数据库的概念，只是描述这个业务功能，仅此而已。
在领域驱动设计的过程中，你会忘记数据库的存在，使用接口注入，我们可以想怎么操作就怎么操作，数据库只是业务场景中数据的存储的一种方式，这个工作应该是你做完所有的业务设计之后执行，如果想进行单元测试，使用 IRepository 接口，我们甚至可以虚拟一切想要的对象（是对象，不是数据值）。
我们再来看下应用层的实现：
1 /** 2 * author:xishuai 3 * address:https://www.github.com/yuezhongxin/MessageManager 4 **/ 5 6 using MessageManager.Domain.DomainModel; 7 using MessageManager.Domain.Repositories; 8 9 namespace MessageManager.Application.Implementation10 {11 /// <summary>12 /// Message管理应用层接口实现13 /// </summary>14 public class MessageServiceImpl : ApplicationService, IMessageService15 {16 #region Private Fields17 private readonly IMessageRepository messageRepository;18 private readonly IUserRepository userRepository;19 #endregion20 21 #region Ctor22 /// <summary>23 /// 初始化一个<c>MessageServiceImpl</c>类型的实例。24 /// </summary>25 /// <param name="context">用来初始化<c>MessageServiceImpl</c>类型的仓储上下文实例。</param>26 /// <param name="messageRepository">“消息”仓储实例。</param>27 /// <param name="userRepository">“用户”仓储实例。</param>28 public MessageServiceImpl(IRepositoryContext context,29 IMessageRepository messageRepository,30 IUserRepository userRepository)31 : base(context)32 {33 this.messageRepository = messageRepository;34 this.userRepository = userRepository;35 }36 #endregion37 38 #region IMessageService Members39 /// <summary>40 /// 发送消息41 /// </summary>42 /// <param name="title">消息标题</param>43 /// <param name="content">消息内容</param>44 /// <param name="sendLoginUserName">发送人-登陆名</param>45 /// <param name="receiveDisplayUserName">接受人-接收人</param>46 /// <returns></returns>47 public bool SendMessage(string title, string content, string sendLoginUserName, string receiveDisplayUserName)48 {49 User sendUser = userRepository.GetUserByLoginName(sendLoginUserName);50 if (sendUser == null)51 {52 return false;53 }54 Message message = new Message(title, content, sendUser);55 User receiveUser = userRepository.GetUserByDisplayName(receiveDisplayUserName);56 if (receiveUser == null)57 {58 return false;59 }60 if (message.Send(receiveUser))61 {62 return true;63 //messageRepository.Add(message);64 //return messageRepository.Context.Commit();65 }66 else67 {68 return false;69 }70 }71 #endregion72 }73 }
你会发现应用层中的 SendMessage 方法，所做的工作流程是多么的行云流水，一步一步的协调（不要误读为业务逻辑，我之前就是这样），完美的完成这个发送消息的请求。应用层的核心是什么？答案就是协调，什么意思？就是说 UI 发出一个请求（比如发消息），然后应用层接到这这个请求之后，进行一些协调处理（比如取想要的用户值，完成发送，以及发送之后的流程－发邮件等等），完成这个工作流程，而并不是这个业务逻辑，业务逻辑是发消息。
在代码注释的地方，完成的是消息的持久化操作，当然我们也可以不完成这个操作，因为业务逻辑是业务逻辑，持久化是持久化，并没有半毛钱关系，我们描述的只是业务场景，仅此而已。
开源地址
- GitHub 开源地址：https://github.com/yuezhongxin/MessageManager
- ASP.NET MVC 发布地址：http://www.xishuaiblog.com:8081/
- ASP.NET WebAPI 发布地址：http://www.xishuaiblog.com:8082/api/Message/GetMessagesBySendUser/小菜
后记
以上只是一个简单业务场景用例，就让我在迷雾森林中迷失自我这么久，到现在只是看到了那一缕阳光而已。DDD 是我们共同的语言，写这篇博文的目的就是，希望园友们也可以看到希望，不要再像我一样，迷失自我。
DDD（领域驱动设计）的过程，从上面一系列的问题更加证明是个迭代过程，一次一次的否决自己，然后再找回自己，反反复复，复复反反，才能成就真正的自己。可能几天或者几周后，看现在的这篇博文就像一坨屎一样，但是没关系，因为我又离真相更进了一步。
我喜欢这个挑战，我也会坚持的完成它，谁叫我热爱它呢，just so so。
如果你觉得本篇文章对你有所帮助，请点击右下部“推荐”，^_^
贴一下，当时寻找的领域模型设计资料，仅作参考：
- https://github.com/sliedig/Employing-the-Domain-Model-Pattern
- http://msdn.microsoft.com/zh-cn/magazine/ee236415.aspx
- http://www.cnblogs.com/1-2-3/category/109191.html
- http://www.cnblogs.com/yimlin/archive/2006/06/15/426929.html
- http://www.blogjava.net/AndersLin/archive/2006/10/09/74187.html
- http://www.blogjava.net/AndersLin/archive/2006/08/25/65875.html