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 : 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 进行协调，然后应用层和就和领域服务通信了，然后的然后。。。

　　有朋友看到这，会觉得没错啊，就是这样啊（如果你也这样认为，那我就去干传销了），先不讨论对错，我们看下领域服务究竟实现的是个什么东西？领域模型变成了什么？应用层又变成了什么？

　　领域服务代码：

 

　　应用层代码：

 

　　领域模型代码：

 

　　其实上面代码，如果是 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