你的位置:首页 > ASP.net教程

[ASP.net教程]DDD实践问题之


之前,在用ENode开发forum案例时,遇到了关于如何实现论坛帖子的回复的统计信息如何更新的问题。后来找到了自己认为比较合理的解决方案,分享给大家。也希望能和大家交流,擦出更多的火花。

论坛核心领域问题分析

论坛领域的核心概念是:帖子、回复。大家都知道,一个帖子可以有零个或多个回复。对同一个帖子,不同的人可以并行发表回复。回复发表后,查看帖子详情时,可以根据回复的发表时间排序显示;此外,我们还关心某个帖子的最新发表的回复、最新回复的作者、最新回复时间,以及总回复数。

我们设计的系统,应该在实现上述的领域问题的前提下,尽量做到发表回复时要快,且能保证帖子能对它的所有回复的统计信息能正确的统计出来。

方案1

把帖子设计为聚合根,回复设计为帖子的子实体。然后发表回复就是在帖子聚合根里添加一个回复实体。

优点:

  1. 模型清晰并符合人们对领域的一般认识,帖子和回复1对多,很自然想到这个模型设计;
  2. 帖子内部就已经聚合了所有的回复信息,数据强一致性,所以统计信息自然不用担心;
  3. 在DB层面,当发表一个回复时,先插入回复,再更新帖子回复统计信息,两个步骤在一个数据库事务里,确保了数据强一致性。

缺点:

  1. 当很多人同时对同一个帖子进行回复时,也就是回复的并发很高时,会被阻塞;因为每个回复都要同步更新帖子的回复统计信息;
  2. 帖子由于聚合了所有的回复,所以会导致帖子本身比较重;必须要求ORM框架支持延迟加载,否则获取帖子会成为一个问题;比如,我仅仅为了修改帖子的内容,而要把整个帖子的回复都加载出来,会付出很多不必要的代价。

这种方案,大部分情况下都没问题。因为大部分论坛,对一个帖子的回复的并发都不会太高。所以,我觉得设计总体来说是可行的。

方案2

把帖子和回复都设计为聚合根,回复不再是帖子内的子实体。发表回复就是新增了一个回复聚合根。

优点:

  1. 帖子聚合根比较轻量级了,因为它内部不在维护回复了;
  2. 高并发创建回复时,不会再有性能问题。但前提是,创建回复后,更新帖子的统计信息必须采用异步的方案,否则如果也是像方案1那样采用同步+事务的方式,那DB层面还是成为瓶颈,并发上不去;

缺点:

  1. 模型一般人理解有点困难,大部分人会问的一个问题是,为何回复不是帖子的子实体,回复不是离开帖子后就没意义了吗?这个问题,这里先不做讨论,我之前的文章中有讨论过这个问题。
  2. 本质问题和方案1类似;如果采用同步更新统计信息,那并发也是上不去,只是模型的设计改变了一下;如果采用异步更新统计信息,那就是消息驱动的架构,就需要考虑消息的丢失、幂等、乱序等问题;比如消息丢失,那统计信息最终就不正确;假如消息重复被处理(分布式消息队列一般不会保证消息绝对不会被重复投递),那统计信息也不正确;假如消息的处理顺序乱序了,那最后的统计信息也会不对;开发人员需要考虑到这些问题。当然,如果你不care,也可以,呵呵。

这种方案,模型层面做了一些变化,DB层面,引入了异步更新统计信息的思想,但要求技术上需要处理EDA架构所带来的典型问题。如果论坛的并发问题确实影响了用户的体验,则可以尝试考虑次方案;

方案3

模型层面,设计为两个聚合根还是一个聚合根无所谓。然后统计信息决定不保存,也就是不冗余存储统计信息了。大家知道,统计信息,一般只是用来展示数据使用,并不会参与到业务逻辑中去。所以,理论上我们不保存统计信息也可以,因为我们总是可以在需要的时候动态查询统计出所需要的信息,SQL的统计功能是很强大的,呵呵。

优点:

  1. 无需冗余存储统计信息,设计简单;
  2. 发表回复时也无并发问题;

缺点:

  1. 需要付出更多的查询代价,尤其是在论坛数据量大,查询并发高的时候;而且还要根据统计信息的结果进行分页的话,数据量一大,性能一定比较糟糕。当然,我们还有办法,比如分库分表,减少单表的数据量,确保查询性能;或者,总是只支持查询近期2周的数据,历史数据不显示,必须通过其他方式查看。这样的话,也可以控制活跃数据在一定的数量级之内;
  2. 上面提到的分库分表,方案显得有点重;只保显示近期活跃的数据相当于牺牲了一部分业务功能,换来更高的查询性能;只要业务上能接受,就可行;

这种方案,我觉得需要业务人员和设计人员仔细评估考量。大家觉得如何呢?

方案4

基于ENode框架实现,采用CQRS架构。领域模型的设计,也是设计为帖子和回复两个聚合根。不同的是帖子中聚合了回复的统计信息,设计一个值对象,表示帖子的当前回复的统计信息。包括:最近回复的ID、作者、回复时间,以及总回复数。为什么要这样设计?因为经过对领域进一步的分析和思考,发现了领域内的一个潜在的业务规则。就是我们关心帖子的“最后”的回复信息。关键问题就是在这个“最后”两个字上。既然是最后,那就必须要知道哪个是最后,根据什么判断?就是根据回复的创建时间。然后,在高并发创建回复的时候,我们需要有一个地方,可以准确的统计出这个最后的回复是哪个。前面几个方案,要么通过DB的强一致性事务保证,要么依赖消息队列的顺序消息处理(必须依靠开发人员要处理好各种EDA的问题才行)。这些方案虽然最终却是能统计出这个最后的回复信息;但我认为,这个是属于领域内的一个业务规则;这个规则是由于我们所关心的统计信息而必须引入的。所以,更好的方案应该是用聚合根来维护这个业务规则。

所以,帖子本身可以不用聚合所有的回复信息,因为帖子本身确实不关心回复信息本身,它只是关心回复的统计信息(最后一个回复的信息以及总回复数);因此,我们设计帖子聚合时,只需要再让其内聚一个包含回复统计信息的值对象即可。

当有一个新的回复产生后,发送一个命令,通知回复的帖子更新其统计信息;然后帖子处理这个命令时,内部判断当前回复的时间是否是最新时间,如果是,则更新最后回复信息和总回复数;如果不是,则只更新回复数。然后帖子的统计信息更新后,产生领域事件,表示帖子的统计信息有更新,然后CQRS的event handler,根据领域事件,更新读库帖子表的那几个统计字段即可;

这种方案,通过ENode提供的技术保证,可以确保消息至少投递一次,确保消息的幂等处理,以及消息(领域事件)的顺序处理,以及最重要的一点,最同一个聚合根,确保尽量做到了无并发操作;就算出现并发,也能框架层面自动重试。所以,开发人员就不用再关心这些技术相关的问题了。

个人认为,这种方案在基于ENode框架引入CQRS架构的异步思路,解决高并发的问题的同时,进一步挖掘了业务需求,分析出了潜在的业务规则,通过用聚合根来维护这个业务规则,最终确保了数据的最终一致性;缺点是,依赖了ENode框架。对我个人来说,肯定是最喜欢这种方式,呵呵。目前enode forum案例,就是采用这种方式来实现帖子的回复统计信息的维护和存储。

不知不觉又下半夜了,眼睛酸,不写了,基本把能想到的都写了,呵呵。