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 的职责问题，我当时是这样分析的：
Repository 应用在应用层，这样就致使应用层和基础层（我把数据持久化放在基础层了）通信，忽略了最重要的领域层，领域层在其中起到的作用最多也就是传递一个非常贫血的领域模型，然后通过 Repository 进行“CRUD”，这样的结果是，应用层不变成所谓的 BLL（常说的业务逻辑层）才怪，另外，因为业务逻辑都放在应用层了，领域模型也变得更加贫血。
乍一看，上面的分析还真没什么问题（看来我还是蛮会忽悠人的，嘿嘿），Repository 服务于领域，所以就必须把 Repository 的调用放在领域层中，领域模型又不能直接和 Repository 通信，所以我后来就把 Domain Service（领域服务）加了进来，让领域服务和 Repository 进行协调，然后应用层和就和领域服务通信了，然后的然后。。。
有朋友看到这，会觉得没错啊，就是这样啊（如果你也这样认为，那我就去干传销了），先不讨论对错，我们看下领域服务究竟实现的是个什么东西？领域模型变成了什么？应用层又变成了什么？
领域服务代码：
应用层代码：
领域模型代码：
其实上面代码，如果是 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.V1
11 {
12 public class User
13 {
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 : IAggregateRoot
11 {
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.Implementation
10 {
11 /// <summary>
12 /// Message管理应用层接口实现
13 /// </summary>
14 public class MessageServiceImpl : ApplicationService, IMessageService
15 {
16 #region Private Fields
17 private readonly IMessageRepository messageRepository;
18 private readonly IUserRepository userRepository;
19 #endregion
20
21 #region Ctor
22 /// <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 #endregion
37
38 #region IMessageService Members
39 /// <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 else
67 {
68 return false;
69 }
70 }
71 #endregion
72 }
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