DDD(领域驱动设计)应对具体业务场景,Domain Model(领域模型)到底如何设计?

DDD(领域驱动设计)应对具体业务场景,Domain Model(领域模型)到底如何设计? 写在前面阅读目录:迷雾森林找回自我开源地址后记毫无疑问,领域驱动设

DDD(领域驱动设计)应对具体业务场景,Domain Model(领域模型)到底如何设计?

写在前面

  阅读目录:

  毫无疑问,领域驱动设计的核心是领域模型,领域模型的核心是实现业务逻辑,也就是说,在应对具体的业务场景的时候,实现业务逻辑是领域驱动设计最重要的一环,在写这篇博文之前,先总结下之前关于 DDD(领域驱动设计)的三篇博文:

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

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

  领域服务代码:

 View Code

  应用层代码:

 View Code

  领域模型代码:

 View Code

  其实上面代码,如果是 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 发出一个请求(比如发消息),然后应用层接到这这个请求之后,进行一些协调处理(比如取想要的用户值,完成发送,以及发送之后的流程-发邮件等等),完成这个工作流程,而并不是这个业务逻辑,业务逻辑是发消息。

  在代码注释的地方,完成的是消息的持久化操作,当然我们也可以不完成这个操作,因为业务逻辑是业务逻辑,持久化是持久化,并没有半毛钱关系,我们描述的只是业务场景,仅此而已。

开源地址

后记

  以上只是一个简单业务场景用例,就让我在迷雾森林中迷失自我这么久,到现在只是看到了那一缕阳光而已。DDD 是我们共同的语言,写这篇博文的目的就是,希望园友们也可以看到希望,不要再像我一样,迷失自我。

  DDD(领域驱动设计)的过程,从上面一系列的问题更加证明是个迭代过程,一次一次的否决自己,然后再找回自己,反反复复,复复反反,才能成就真正的自己。可能几天或者几周后,看现在的这篇博文就像一坨屎一样,但是没关系,因为我又离真相更进了一步。

  我喜欢这个挑战,我也会坚持的完成它,谁叫我热爱它呢,just so so。

  如果你觉得本篇文章对你有所帮助,请点击右下部“推荐”,^_^

  贴一下,当时寻找的领域模型设计资料,仅作参考: