写在前面
除了博文内容之外，和 netfocus 兄的讨论，也可以让你学到很多（至少我是这样），不要错过哦。
阅读目录：
毫无疑问，领域驱动设计的核心是领域模型，领域模型的核心是实现业务逻辑，也就是说，在应对具体的业务场景的时候，实现业务逻辑是领域驱动设计最重要的一环，在写这篇博文之前，先总结下之前关于 DDD（领域驱动设计）的三篇博文：
我的“第一次”，就这样没了：DDD（领域驱动设计）理论结合实践：伪领域驱动设计，只是用 .NET 实现的一个“空壳”，仅此而已。
一缕阳光：DDD（领域驱动设计）应对具体业务场景，如何聚焦 Domain Model（领域模型）？：只是聚焦领域模型（认清各个部分的职责，让设计的焦点集中在领域模型中），文中关于领域模型的实现就是一个“渣”，仅此而已。
死去活来，而不变质：Domain Model（领域模型） 和 EntityFramework 如何正确进行对象关系映射？：走了个弯路，ORM 的映射关系及仓储的实现，应该是在本篇内容之后探讨，原因都是脚本驱动模式惹的祸，如果说脚本驱动模式是恶魔（特定的环境，也有好处，不能一概而论，这边只是一个比喻），那领域驱动设计可以看作是天使，心里想的是天使，却听了恶魔的话，为什么？因为它在你心中已根深蒂固，仅此而已。
OO（面向对象）设计指导我们要面向（停顿一下）对象设计，也就是说你要去面向这个对象，去思考它的本质，说白了就是思考：它是从哪里来，到哪里去，生长轨迹，拥有的事物，自身的变化规律，现在的状态等等方面，更深入一点就是站在哲学的角度去思考万物的本质（请参考老子的道德经），咳咳，说大了。
但是，在现实生活中，我们是做软件设计的程序员，需要做出东西给用户用的，而不是像老子那样逍遥的每天面对星空，去思考宇宙万物（如果有兴趣，你也可以试试，只要不被你的女朋友骂死）。也就是说我们要面对具体的业务场景，而并非只是单纯的 OO，这就要求我们除了要 OO 之外，还要去探讨业务逻辑的本质以及实现。
以下内容是本人掉的一个又一个深坑，拼死爬了上来，在 DDD 的道路上，友情提醒各位：前方有坑，园友们请小心谨慎。
迷雾森林
迷雾森林中，切勿迷失自我，不幸的是，我就这样迷失了：
具体的业务场景还是短消息系统－MessageManager，存在 Message 和 User 两个领域模型，业务逻辑：一个用户给另一个用户发送消息，就是这么简单，可以看作是一个最简单的业务逻辑，当然在发送消息这个过程中会有其他的业务逻辑，先不探讨 Message 领域模型和 User 领域模型如何协调完成这个业务逻辑，我们先看以下，我在第一篇《我的“第一次”，就这样没了：DDD（领域驱动设计）理论结合实践》博文中，关于领域模型的实现：
/**
* author:xishaui
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using System; namespace MessageManager.Domain.DomainModel
{
public class Message : IAggregateRoot
{
#region 构造方法
public Message()
{
this.ID = Guid.NewGuid().ToString();
}
#endregion #region 实体成员
public string FromUserID { get; set; }
public string FromUserName { get; set; }
public string ToUserID { get; set; }
public string ToUserName { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public DateTime SendTime { get; set; }
public bool IsRead { get; set; }
public virtual User FromUser { get; set; }
public virtual User ToUser { get; set; }
#endregion #region IEntity成员
/// <summary>
/// 获取或设置当前实体对象的全局唯一标识。
/// </summary>
public string ID { get; set; }
#endregion
}
}
Are you kidding me？不，你没看错，以上就是 Message 领域模型的实现代码，User 领域模型的代码我就不贴了，比这个还要简单，只包含 ID 和 Name 两个字段属性，领域驱动设计主张的是充血模型，只包含字段属性的领域模型是极其贫血的，像上面的 Message 领域模型，充血的领域模型实现的是业务逻辑。上面我们说的发送消息这个业务逻辑，在领域模型中为什么没有体现？既然是基于领域驱动设计，那为什么我还要这样设计呢？这是为什么呢？当时设计完之后，我也在思考这个问题，难道脑袋有问题？不可能吧？看下应用层的代码就知道了：
/**
* author:xishuai
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using AutoMapper;
using MessageManager.Application.DTO;
using MessageManager.Domain.DomainModel;
using MessageManager.Domain.Repositories;
using System.Collections.Generic; namespace MessageManager.Application.Implementation
{
/// <summary>
/// Message管理应用层接口实现
/// </summary>
public class MessageServiceImpl : ApplicationService, IMessageService
{
#region Private Fields
private readonly IMessageRepository messageRepository;
private readonly IUserRepository userRepository;
#endregion #region Ctor
/// <summary>
/// 初始化一个<c>MessageServiceImpl</c>类型的实例。
/// </summary>
/// <param name="context">用来初始化<c>MessageServiceImpl</c>类型的仓储上下文实例。</param>
/// <param name="messageRepository">“消息”仓储实例。</param>
/// <param name="userRepository">“用户”仓储实例。</param>
public MessageServiceImpl(IRepositoryContext context,
IMessageRepository messageRepository,
IUserRepository userRepository)
: base(context)
{
this.messageRepository = messageRepository;
this.userRepository = userRepository;
}
#endregion #region IMessageService Members
/// <summary>
/// 通过发送方获取消息列表
/// </summary>
/// <param name="userDTO">发送方</param>
/// <returns>消息列表</returns>
public IEnumerable<MessageDTO> GetMessagesBySendUser(UserDTO sendUserDTO)
{
//User user = userRepository.GetUserByName(sendUserDTO.Name);
var messages = messageRepository.GetMessagesBySendUser(Mapper.Map<UserDTO, User>(sendUserDTO));
if (messages == null)
return null;
var ret = new List<MessageDTO>();
foreach (var message in messages)
{
ret.Add(Mapper.Map<Message, MessageDTO>(message));
}
return ret;
}
/// <summary>
/// 通过接受方获取消息列表
/// </summary>
/// <param name="userDTO">接受方</param>
/// <returns>消息列表</returns>
public IEnumerable<MessageDTO> GetMessagesByReceiveUser(UserDTO receiveUserDTO)
{
//User user = userRepository.GetUserByName(receiveUserDTO.Name);
var messages = messageRepository.GetMessagesByReceiveUser(Mapper.Map<UserDTO, User>(receiveUserDTO));
if (messages == null)
return null;
var ret = new List<MessageDTO>();
foreach (var message in messages)
{
ret.Add(Mapper.Map<Message, MessageDTO>(message));
}
return ret;
}
/// <summary>
/// 删除消息
/// </summary>
/// <param name="messageDTO"></param>
/// <returns></returns>
public bool DeleteMessage(MessageDTO messageDTO)
{
messageRepository.Remove(Mapper.Map<MessageDTO, Message>(messageDTO));
return messageRepository.Context.Commit();
}
/// <summary>
/// 发送消息
/// </summary>
/// <param name="messageDTO"></param>
/// <returns></returns>
public bool SendMessage(MessageDTO messageDTO)
{
Message message = Mapper.Map<MessageDTO, Message>(messageDTO);
message.FromUserID = userRepository.GetUserByName(messageDTO.FromUserName).ID;
message.ToUserID = userRepository.GetUserByName(messageDTO.ToUserName).ID;
messageRepository.Add(message);
return messageRepository.Context.Commit();
}
/// <summary>
/// 查看消息
/// </summary>
/// <param name="ID"></param>
/// <returns></returns>
public MessageDTO ShowMessage(string ID, string isRead)
{
Message message = messageRepository.GetByKey(ID);
if (isRead == "")
{
message.IsRead = true;
messageRepository.Update(message);
messageRepository.Context.Commit();
}
return Mapper.Map<Message, MessageDTO>(message);
}
#endregion
}
}
可以看到应用层的代码真是不忍直视，撇开其他操作，我们看下 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 进行协调，然后应用层和就和领域服务通信了，然后的然后。。。
有朋友看到这，会觉得没错啊，就是这样啊（如果你也这样认为，那我就去干传销了），先不讨论对错，我们看下领域服务究竟实现的是个什么东西？领域模型变成了什么？应用层又变成了什么？
领域服务代码：
/**
* author:xishuai
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using MessageManager.Domain.DomainModel;
using MessageManager.Domain.Repositories;
using System.Collections.Generic; namespace MessageManager.Domain.DomainService
{
/// <summary>
/// Message领域服务实现
/// </summary>
public class MessageDomainService : IMessageDomainService
{
#region Private Fields
private readonly IMessageRepository messageRepository;
private readonly IUserRepository userRepository;
#endregion #region Ctor
public MessageDomainService(IMessageRepository messageRepository, IUserRepository userRepository)
{
this.messageRepository = messageRepository;
this.userRepository = userRepository;
}
#endregion #region IMessageDomainService Members
public bool DeleteMessage(Message message)
{
messageRepository.Remove(message);
return messageRepository.Context.Commit();
}
public bool SendMessage(Message message)
{
message.LoadUserName(userRepository.GetUser(new User { Name = message.FromUserName })
, userRepository.GetUser(new User { Name = message.ToUserName }));
messageRepository.Add(message);
return messageRepository.Context.Commit();
}
public Message ShowMessage(string id, User currentUser)
{
Message message = messageRepository.GetByKey(id);
message.ReadMessage(userRepository.GetUser(new User { Name = currentUser.Name }));
messageRepository.Update(message);
messageRepository.Context.Commit();
return message;
}
public IEnumerable<Message> GetMessagesBySendUser(User user)
{
User userResult = userRepository.GetUser(user);
return messageRepository.GetMessagesBySendUser(userResult);
}
public IEnumerable<Message> GetMessagesByReceiveUser(User user)
{
User userResult = userRepository.GetUser(user);
return messageRepository.GetMessagesByReceiveUser(userResult);
}
public int GetNoReadCount(User user)
{
User userResult = userRepository.GetUser(user);
return messageRepository.GetNoReadCount(userResult);
}
#endregion
}
}
应用层代码：
/**
* author:xishuai
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using AutoMapper;
using MessageManager.Application.DTO;
using MessageManager.Domain.DomainModel;
using MessageManager.Domain.DomainService;
using System.Collections.Generic; namespace MessageManager.Application.Implementation
{
/// <summary>
/// Message管理应用层接口实现
/// </summary>
public class MessageServiceImpl : ApplicationService, IMessageService
{
#region Private Fields
private readonly IMessageDomainService messageService;
#endregion #region Ctor
/// <summary>
/// 初始化一个<c>MessageServiceImpl</c>类型的实例。
/// </summary>
/// <param name="messageRepository">“消息”服务实例。</param>
public MessageServiceImpl(IMessageDomainService messageService)
{
this.messageService = messageService;
}
#endregion #region IMessageService Members
/// <summary>
/// 通过发送方获取消息列表
/// </summary>
/// <param name="userDTO">发送方</param>
/// <returns>消息列表</returns>
public IEnumerable<MessageDTO> GetMessagesBySendUser(UserDTO sendUserDTO)
{
//User user = userRepository.GetUserByName(sendUserDTO.Name);
var messages = messageService.GetMessagesBySendUser(Mapper.Map<UserDTO, User>(sendUserDTO));
if (messages == null)
return null;
var ret = new List<MessageDTO>();
foreach (var message in messages)
{
ret.Add(Mapper.Map<Message, MessageDTO>(message));
}
return ret;
}
/// <summary>
/// 通过接受方获取消息列表
/// </summary>
/// <param name="userDTO">接受方</param>
/// <returns>消息列表</returns>
public IEnumerable<MessageDTO> GetMessagesByReceiveUser(UserDTO receiveUserDTO)
{
//User user = userRepository.GetUserByName(receiveUserDTO.Name);
var messages = messageService.GetMessagesByReceiveUser(Mapper.Map<UserDTO, User>(receiveUserDTO));
if (messages == null)
return null;
var ret = new List<MessageDTO>();
foreach (var message in messages)
{
ret.Add(Mapper.Map<Message, MessageDTO>(message));
}
return ret;
}
/// <summary>
/// 删除消息
/// </summary>
/// <param name="messageDTO"></param>
/// <returns></returns>
public bool DeleteMessage(MessageDTO messageDTO)
{
return messageService.DeleteMessage(Mapper.Map<MessageDTO, Message>(messageDTO));
}
/// <summary>
/// 发送消息
/// </summary>
/// <param name="messageDTO"></param>
/// <returns></returns>
public bool SendMessage(MessageDTO messageDTO)
{
return messageService.SendMessage(Mapper.Map<MessageDTO, Message>(messageDTO));
}
/// <summary>
/// 查看消息
/// </summary>
/// <param name="ID"></param>
/// <returns></returns>
public MessageDTO ShowMessage(string id, UserDTO currentUserDTO)
{
Message message = messageService.ShowMessage(id, Mapper.Map<UserDTO, User>(currentUserDTO));
return Mapper.Map<Message, MessageDTO>(message);
}
/// <summary>
/// 获取未读消息数
/// </summary>
/// <param name="user"></param>
/// <returns></returns>
public int GetNoReadCount(UserDTO userDTO)
{
return messageService.GetNoReadCount(Mapper.Map<UserDTO, User>(userDTO));
}
#endregion
}
}
领域模型代码：
/**
* author:xishaui
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using System; namespace MessageManager.Domain.DomainModel
{
public class Message : IAggregateRoot
{
#region 构造方法
public Message()
{
this.ID = Guid.NewGuid().ToString();
}
#endregion #region 实体成员
public string FromUserID { get; set; }
public string FromUserName { get; set; }
public string ToUserID { get; set; }
public string ToUserName { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public DateTime SendTime { get; set; }
public bool IsRead { get; set; }
public virtual User FromUser { get; set; }
public virtual User ToUser { get; set; }
#endregion #region 业务逻辑
/// <summary>
/// 阅读消息
/// </summary>
/// <param name="CurrentUser"></param>
public void ReadMessage(User currentUser)
{
if (!this.IsRead && currentUser.ID.Equals(ToUserID))
{
this.IsRead = true;
}
}
/// <summary>
/// 加载用户
/// </summary>
/// <param name="sendUser"></param>
/// <param name="receiveUser"></param>
public void LoadUserName(User sendUser, User receiveUser)
{
this.FromUserID = sendUser.ID;
this.ToUserID = receiveUser.ID;
}
#endregion #region IEntity成员
/// <summary>
/// 获取或设置当前实体对象的全局唯一标识。
/// </summary>
public string ID { get; set; }
#endregion
}
}
其实上面代码，如果是 DDD 大神来看的话，他只要看领域模型中的代码就行了，因为领域驱动设计的核心就是领域模型，那领域模型变成了什么？只是添加了 ReadMessage 和 LoadUserName 两个不是业务逻辑的业务逻辑方法（因为只有他们两个，如果把他们两个去掉，就变回原来的贫血模型了，所以，你懂的），领域服务中的 SendMessage 方法变的和原来的应用层代码一样，要说变化的话，只是把 Application 单词变成了 Domain Service 这个单词，其他无任何变化，应用层的代码也就变成了下面这样：
/// <summary>
/// 发送消息
/// </summary>
/// <param name="messageDTO"></param>
/// <returns></returns>
public bool SendMessage(MessageDTO messageDTO)
{
return messageService.SendMessage(Mapper.Map<MessageDTO, Message>(messageDTO));
}
在领域驱动设计中，应用层的定义是很薄的一层，可以看到，上面的应用层代码也未免太薄了吧，为什么？因为原来它的工作让领域服务做了，导致现在变成了一个调用外壳（也就是可有可无的东西，没有任何意义）。
》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》分割线《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《
为什么会有分割线？因为在应对具体业务场景中，上面做的操作都是无用功，为什么？因为设计的领域模型中什么东西都没有（指的是业务逻辑），没有任何东西的领域模型，还是真正的领域驱动设计吗？关于这个问题，*都知道，当然我也不傻，嘿嘿。
认识到这个根本问题后，下面就抛开一切外在因素，比如领域服务、仓储、应用层、表现层等等，这些统统不管，只做领域模型的设计，让真正的设计焦点集中在领域模型上，然后再针对领域模型做单元测试。
对，就是这么简单，至少听起来的确简单，事实真是这样吗？我却不这样认为，因为就是这个简单的问题，我为此痛苦了两三天的时间，说夸张点就是：吃不下饭，睡不着觉，在这个过程中，领域模型的一行代码我也没有写，不是不想写，而是不知道如何写？这是最最痛苦的，真是体会到了才知道。写不出来怎么办？我就找遍网上所有关于领域模型设计的资料（大部分都是英文，只能很痛苦的看），还有《领域驱动设计》和《企业应用架构模式》这两本书，希望能从中找到些灵感（就像画画，难点就在如何画第一笔），并不是模仿，这个也模仿不来，因为每个业务场景都不相同，遗憾的是没有找到任何的灵感，唯一找到的线索就是 OO 设计（大家都知道，我却不知道，因为蒙了）。
既然是要面向对象，那就分析一下对象，主要包含两个：用户和消息。对象拥有自身的属性、状态和行为，发送消息是用户的一种行为，所以发送消息这个操作应该放在用户中，那现在消息只有自身的一些属性值，因为在面向对象中，它是固定的，只有通过用户来调用它，用户领域模型代码如下：
/**
* author:xishaui
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using MessageManager.Domain.Demo.V1.Event;
using System;
using System.Collections.Generic; namespace MessageManager.Domain.Demo.V1
{
public class User
{
public User()
{
this.ID = Guid.NewGuid().ToString();
} public string ID { get; set; }
public string Name { get; set; }
public virtual ICollection<Message> SendMessages { get; set; }
public virtual ICollection<Message> ReceiveMessages { get; set; } public void SendMessage(Message message)
{
User toUser = GetUser(message.ToUser);
if (toUser == null)
{
throw new NotImplementedException();
}
message.FromUser = this;
message.ToUser = toUser;
this.SendMessages.Add(message);
toUser.ReceiveMessages.Add(message);
DomainEvents.Raise(new MessageEvent() { DoMessage = message });
///
}
}
}
按照面向对象设计，消息是用户的附属对象，只有用户存在，消息才有意义，一个用户对象拥有多个消息的对象集合，那怎么体现出发送消息这个动作呢？答案就是：this.SendMessages.Add(message) 这段代码，表示往用户对象的消息集合填充消息对象，这样就会相对于用户对象来说，这条消息的发送动作就完成了。先不考虑这样设计的合理或者不合理，我们看下消息模型中的代码，就会发现里面只有一些字段属性，没有任何的操作，还有就是如果我们要添加消息的其他动作，比如查找，删除等等，按照上面的分析，我们就会在用户对象中添加这些操作，因为这些动作都是用户所具有的，合理吗？至少听起来就不合理。
身处这个迷雾森林，才知道它的恐怖之处，不断的迷失自我，以致最后可能连自己都不相信，并怀疑自己。
找回自我
在迷雾森林之中，如何找回自我？而不迷失，没有确切的答案，我只能寻觅那一缕阳光一步一步的往前行。。。
首先，Repository，和你说声抱歉，非常抱歉，让你蒙冤，是我误会你了，因为我对业务逻辑的不理解，以致做出错误的做法。
回到短消息系统－MessageManager，需要注意的是，我们做的是消息系统，一切的一切都应该围绕 Message 领域模型展开，在这个系统中，最重要的就是发送消息这个业务逻辑，什么叫发消息？不要被上面的面向对象所迷惑，只考虑发消息这个具体的业务，我们来分析一下：比如在现实生活中，我们要给女朋友写信，首先我们要写信的内容，写完之后，要写一下女朋友的地址信息及名字，这个写信才算完成，邮递员邮递并不在这个业务逻辑之内了，因为这封信我写上收件人之后，这封信相对于我来说就已经发出了，后面只不过是收件人收不收得到的问题了（即使我写好，没有寄出去）。也就是说邮递员邮递这个工作过程相当于数据的持久化，写信的这个过程就是邮递（发消息的业务逻辑），just it。
理解上面的内容很重要，然后我们再来看 Message 这个领域模型，创建这个对象的时候，就说明我们已经把消息的内容写好了，也就是必要的东西，比如：消息标题、消息内容、发送人、发送时间等等，用代码实现就是在 Message 领域模型中的构造函数传递必要值，代码如下：
/**
* author:xishuai
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using System; namespace MessageManager.Domain.DomainModel
{
public class Message : IAggregateRoot
{
public Message(string title, string content, User sendUser)
{
if (title.Equals("") || content.Equals("") || sendUser == null)
{
throw new ArgumentNullException();
}
this.ID = Guid.NewGuid().ToString();
this.Title = title;
this.Content = content;
this.SendTime = DateTime.Now;
this.State = MessageState.NoRead;
this.SendUser = sendUser;
}
public string ID { get; set; }
public string Title { get; set; }
public string Content { get; set; }
public DateTime SendTime { get; set; }
public MessageState State { get; set; }
public virtual User SendUser { get; set; }
public virtual User ReceiveUser { get; set; } public bool Send(User receiveUser)
{
if (receiveUser == null)
{
throw new ArgumentNullException();
}
this.ReceiveUser = receiveUser;
return true;
///to do...
}
}
}
在实例 Message 领域模型之前要对必要值进行判断，发送消息的关键代码就是：ReceiveUser = receiveUser，表示为这条消息“贴上”收件人的标签，指示这条消息的发送动作已经完成，当然在这个 Send 业务方法中可能还会有其他业务逻辑的加入，其实发送消息就是这样，在 Message 这个领域模型中，没有什么数据库的概念，只是描述这个业务功能，仅此而已。
在领域驱动设计的过程中，你会忘记数据库的存在，使用接口注入，我们可以想怎么操作就怎么操作，数据库只是业务场景中数据的存储的一种方式，这个工作应该是你做完所有的业务设计之后执行，如果想进行单元测试，使用 IRepository 接口，我们甚至可以虚拟一切想要的对象（是对象，不是数据值）。
我们再来看下应用层的实现：
/**
* author:xishuai
* address:https://www.github.com/yuezhongxin/MessageManager
**/ using MessageManager.Domain.DomainModel;
using MessageManager.Domain.Repositories; namespace MessageManager.Application.Implementation
{
/// <summary>
/// Message管理应用层接口实现
/// </summary>
public class MessageServiceImpl : ApplicationService, IMessageService
{
#region Private Fields
private readonly IMessageRepository messageRepository;
private readonly IUserRepository userRepository;
#endregion #region Ctor
/// <summary>
/// 初始化一个<c>MessageServiceImpl</c>类型的实例。
/// </summary>
/// <param name="context">用来初始化<c>MessageServiceImpl</c>类型的仓储上下文实例。</param>
/// <param name="messageRepository">“消息”仓储实例。</param>
/// <param name="userRepository">“用户”仓储实例。</param>
public MessageServiceImpl(IRepositoryContext context,
IMessageRepository messageRepository,
IUserRepository userRepository)
: base(context)
{
this.messageRepository = messageRepository;
this.userRepository = userRepository;
}
#endregion #region IMessageService Members
/// <summary>
/// 发送消息
/// </summary>
/// <param name="title">消息标题</param>
/// <param name="content">消息内容</param>
/// <param name="sendLoginUserName">发送人-登陆名</param>
/// <param name="receiveDisplayUserName">接受人-接收人</param>
/// <returns></returns>
public bool SendMessage(string title, string content, string sendLoginUserName, string receiveDisplayUserName)
{
User sendUser = userRepository.GetUserByLoginName(sendLoginUserName);
if (sendUser == null)
{
return false;
}
Message message = new Message(title, content, sendUser);
User receiveUser = userRepository.GetUserByDisplayName(receiveDisplayUserName);
if (receiveUser == null)
{
return false;
}
if (message.Send(receiveUser))
{
return true;
//messageRepository.Add(message);
//return messageRepository.Context.Commit();
}
else
{
return false;
}
}
#endregion
}
}
你会发现应用层中的 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