拨开迷雾,找回自我:DDD 应对具体业务场景,Domain Model 到底如何设计?

迷雾森林

迷雾森林中,切勿迷失自我,不幸的是,我就这样迷失了:

具体的业务场景还是短消息系统-MessageManager,存在 Message 和 User 两个领域模型,业务逻辑:一个用户给另一个用户发送消息,就是这么简单,可以看作是一个最简单的业务逻辑,当然在发送消息这个过程中会有其他的业务逻辑,先不探讨 Message 领域模型和 User 领域模型如何协调完成这个业务逻辑,我们先看以下,我在第一篇《我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践》博文中,关于领域模型的实现:

Are you kidding me?不,你没看错,以上就是 Message 领域模型的实现代码,User 领域模型的代码我就不贴了,比这个还要简单,只包含 ID 和 Name 两个字段属性,领域驱动设计主张的是充血模型,只包含字段属性的领域模型是极其贫血的,像上面的 Message 领域模型,充血的领域模型实现的是业务逻辑。上面我们说的发送消息这个业务逻辑,在领域模型中为什么没有体现?既然是基于领域驱动设计,那为什么我还要这样设计呢?这是为什么呢?当时设计完之后,我也在思考这个问题,难道脑袋有问题?不可能吧?看下应用层的代码就知道了:

可以看到应用层的代码真是不忍直视,撇开其他操作,我们看下 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 这个单词,其他无任何变化,应用层的代码也就变成了下面这样:

在领域驱动设计中,应用层的定义是很薄的一层,可以看到,上面的应用层代码也未免太薄了吧,为什么?因为原来它的工作让领域服务做了,导致现在变成了一个调用外壳(也就是可有可无的东西,没有任何意义)。

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》分割线《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《《

为什么会有分割线?因为在应对具体业务场景中,上面做的操作都是无用功,为什么?因为设计的领域模型中什么东西都没有(指的是业务逻辑),没有任何东西的领域模型,还是真正的领域驱动设计吗?关于这个问题,傻子都知道,当然我也不傻,嘿嘿。

认识到这个根本问题后,下面就抛开一切外在因素,比如领域服务、仓储、应用层、表现层等等,这些统统不管,只做领域模型的设计,让真正的设计焦点集中在领域模型上,然后再针对领域模型做单元测试。

对,就是这么简单,至少听起来的确简单,事实真是这样吗?我却不这样认为,因为就是这个简单的问题,我为此痛苦了两三天的时间,说夸张点就是:吃不下饭,睡不着觉,在这个过程中,领域模型的一行代码我也没有写,不是不想写,而是不知道如何写?这是最最痛苦的,真是体会到了才知道。写不出来怎么办?我就找遍网上所有关于领域模型设计的资料(大部分都是英文,只能很痛苦的看),还有《领域驱动设计》和《企业应用架构模式》这两本书,希望能从中找到些灵感(就像画画,难点就在如何画第一笔),并不是模仿,这个也模仿不来,因为每个业务场景都不相同,遗憾的是没有找到任何的灵感,唯一找到的线索就是 OO 设计(大家都知道,我却不知道,因为蒙了)。

既然是要面向对象,那就分析一下对象,主要包含两个:用户和消息。对象拥有自身的属性、状态和行为,发送消息是用户的一种行为,所以发送消息这个操作应该放在用户中,那现在消息只有自身的一些属性值,因为在面向对象中,它是固定的,只有通过用户来调用它,用户领域模型代码如下:

按照面向对象设计,消息是用户的附属对象,只有用户存在,消息才有意义,一个用户对象拥有多个消息的对象集合,那怎么体现出发送消息这个动作呢?答案就是:this.SendMessages.Add(message) 这段代码,表示往用户对象的消息集合填充消息对象,这样就会相对于用户对象来说,这条消息的发送动作就完成了。先不考虑这样设计的合理或者不合理,我们看下消息模型中的代码,就会发现里面只有一些字段属性,没有任何的操作,还有就是如果我们要添加消息的其他动作,比如查找,删除等等,按照上面的分析,我们就会在用户对象中添加这些操作,因为这些动作都是用户所具有的,合理吗?至少听起来就不合理。

身处这个迷雾森林,才知道它的恐怖之处,不断的迷失自我,以致最后可能连自己都不相信,并怀疑自己。

找回自我

在迷雾森林之中,如何找回自我?而不迷失,没有确切的答案,我只能寻觅那一缕阳光一步一步的往前行。。。

首先,Repository,和你说声抱歉,非常抱歉,让你蒙冤,是我误会你了,因为我对业务逻辑的不理解,以致做出错误的做法。

回到短消息系统-MessageManager,需要注意的是,我们做的是消息系统,一切的一切都应该围绕 Message 领域模型展开,在这个系统中,最重要的就是发送消息这个业务逻辑,什么叫发消息?不要被上面的面向对象所迷惑,只考虑发消息这个具体的业务,我们来分析一下:比如在现实生活中,我们要给女朋友写信,首先我们要写信的内容,写完之后,要写一下女朋友的地址信息及名字,这个写信才算完成,邮递员邮递并不在这个业务逻辑之内了,因为这封信我写上收件人之后,这封信相对于我来说就已经发出了,后面只不过是收件人收不收得到的问题了(即使我写好,没有寄出去)。也就是说邮递员邮递这个工作过程相当于数据的持久化,写信的这个过程就是邮递(发消息的业务逻辑),just it。

理解上面的内容很重要,然后我们再来看 Message 这个领域模型,创建这个对象的时候,就说明我们已经把消息的内容写好了,也就是必要的东西,比如:消息标题、消息内容、发送人、发送时间等等,用代码实现就是在 Message 领域模型中的构造函数传递必要值,代码如下:

在实例 Message 领域模型之前要对必要值进行判断,发送消息的关键代码就是:ReceiveUser = receiveUser,表示为这条消息“贴上”收件人的标签,指示这条消息的发送动作已经完成,当然在这个 Send 业务方法中可能还会有其他业务逻辑的加入,其实发送消息就是这样,在 Message 这个领域模型中,没有什么数据库的概念,只是描述这个业务功能,仅此而已。

在领域驱动设计的过程中,你会忘记数据库的存在,使用接口注入,我们可以想怎么操作就怎么操作,数据库只是业务场景中数据的存储的一种方式,这个工作应该是你做完所有的业务设计之后执行,如果想进行单元测试,使用 IRepository 接口,我们甚至可以虚拟一切想要的对象(是对象,不是数据值)。

我们再来看下应用层的实现:

你会发现应用层中的 SendMessage 方法,所做的工作流程是多么的行云流水,一步一步的协调(不要误读为业务逻辑,我之前就是这样),完美的完成这个发送消息的请求。应用层的核心是什么?答案就是协调,什么意思?就是说 UI 发出一个请求(比如发消息),然后应用层接到这这个请求之后,进行一些协调处理(比如取想要的用户值,完成发送,以及发送之后的流程-发邮件等等),完成这个工作流程,而并不是这个业务逻辑,业务逻辑是发消息。

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

开源地址

后记

022139500437455

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

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

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

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

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部