DDD实践问题之 - 关于论坛的帖子回复统计信息的更新的思考
原文来自：DDD实践问题之 - 关于论坛的帖子回复统计信息的更新的思考-阿里云开发者社区 (aliyun.com)
之前，在用ENode开发forum案例时，遇到了关于如何实现论坛帖子的回复的统计信息如何更新的问题。后来找到了自己认为比较合理的解决方案，分享给大家。也希望能和大家交流，擦出更多的火花。
论坛核心领域问题分析
论坛领域的核心概念是：帖子、回复。大家都知道，一个帖子可以有零个或多个回复。对同一个帖子，不同的人可以并行发表回复。回复发表后，查看帖子详情时，可以根据回复的发表时间排序显示；此外，我们还关心某个帖子的最新发表的回复、最新回复的作者、最新回复时间，以及总回复数。
我们设计的系统，应该在实现上述的领域问题的前提下，尽量做到发表回复时要快，且能保证帖子能对它的所有回复的统计信息能正确的统计出来。
方案1
把帖子设计为聚合根，回复设计为帖子的子实体。然后发表回复就是在帖子聚合根里添加一个回复实体。
优点：
- 模型清晰并符合人们对领域的一般认识，帖子和回复1对多，很自然想到这个模型设计；
- 帖子内部就已经聚合了所有的回复信息，数据强一致性，所以统计信息自然不用担心；
- 在DB层面，当发表一个回复时，先插入回复，再更新帖子回复统计信息，两个步骤在一个数据库事务里，确保了数据强一致性。
缺点：
- 当很多人同时对同一个帖子进行回复时，也就是回复的并发很高时，会被阻塞；因为每个回复都要同步更新帖子的回复统计信息；
- 帖子由于聚合了所有的回复，所以会导致帖子本身比较重；必须要求ORM框架支持延迟加载，否则获取帖子会成为一个问题；比如，我仅仅为了修改帖子的内容，而要把整个帖子的回复都加载出来，会付出很多不必要的代价。
这种方案，大部分情况下都没问题。因为大部分论坛，对一个帖子的回复的并发都不会太高。所以，我觉得设计总体来说是可行的。
方案2
把帖子和回复都设计为聚合根，回复不再是帖子内的子实体。发表回复就是新增了一个回复聚合根。
优点：
- 帖子聚合根比较轻量级了，因为它内部不在维护回复了；
- 高并发创建回复时，不会再有性能问题。但前提是，创建回复后，更新帖子的统计信息必须采用异步的方案，否则如果也是像方案1那样采用同步+事务的方式，那DB层面还是成为瓶颈，并发上不去；
缺点：
- 模型一般人理解有点困难，大部分人会问的一个问题是，为何回复不是帖子的子实体，回复不是离开帖子后就没意义了吗？这个问题，这里先不做讨论，我之前的文章中有讨论过这个问题。
- 本质问题和方案1类似；如果采用同步更新统计信息，那并发也是上不去，只是模型的设计改变了一下；如果采用异步更新统计信息，那就是消息驱动的架构，就需要考虑消息的丢失、幂等、乱序等问题；比如消息丢失，那统计信息最终就不正确；假如消息重复被处理（分布式消息队列一般不会保证消息绝对不会被重复投递），那统计信息也不正确；假如消息的处理顺序乱序了，那最后的统计信息也会不对；开发人员需要考虑到这些问题。当然，如果你不care，也可以，呵呵。
这种方案，模型层面做了一些变化，DB层面，引入了异步更新统计信息的思想，但要求技术上需要处理EDA架构所带来的典型问题。如果论坛的并发问题确实影响了用户的体验，则可以尝试考虑次方案；
方案3
模型层面，设计为两个聚合根还是一个聚合根无所谓。然后统计信息决定不保存，也就是不冗余存储统计信息了。大家知道，统计信息，一般只是用来展示数据使用，并不会参与到业务逻辑中去。所以，理论上我们不保存统计信息也可以，因为我们总是可以在需要的时候动态查询统计出所需要的信息，SQL的统计功能是很强大的，呵呵。
优点：
- 无需冗余存储统计信息，设计简单；
- 发表回复时也无并发问题；
缺点：
- 需要付出更多的查询代价，尤其是在论坛数据量大，查询并发高的时候；而且还要根据统计信息的结果进行分页的话，数据量一大，性能一定比较糟糕。当然，我们还有办法，比如分库分表，减少单表的数据量，确保查询性能；或者，总是只支持查询近期2周的数据，历史数据不显示，必须通过其他方式查看。这样的话，也可以控制活跃数据在一定的数量级之内；
- 上面提到的分库分表，方案显得有点重；只保显示近期活跃的数据相当于牺牲了一部分业务功能，换来更高的查询性能；只要业务上能接受，就可行；
这种方案，我觉得需要业务人员和设计人员仔细评估考量。大家觉得如何呢？
方案4
这种方案，一般老外的开源论坛中出现的较多。领域模型的设计有较大不同，因为对论坛核心领域的认识有所不同。当用户发帖时，我们把帖子的标题和内容看成两个部分，标题叫thread，内容是属于这个thread下的第一个message；然后对这个帖子的回复，看成是第二个message。所以，通过这样的理解，thread还是可以理解为帖子，但其含义和我们通常所理解的帖子稍微有点不同，因为这个帖子仅仅只有标题没有内容，它的作用就是“穿针引线”，thread的英文意思就是线索、穿成串的意思。可见，一个thread就是对很多message的串联，我们也可以把thread理解为一个主题，这个主题下有若干个讨论内容。然后一个message，即消息，就表达了一个内容。所以，当用户发帖时，就是会生成一个thread，以及一个message，两个聚合根；当用户发表回复时，就是只是创建一个message聚合根。另外，也很明显thread应该维护所有的回复的统计信息，因为我们设计它的目的也在于此（串联message，以及维护message统计信息）。然后，message就是简单的表达某个内容即可，同时message上记录当前自己所属的threadId即可。好像说的有点啰嗦，呵呵！
上面这个描述的是我们对论坛核心领域有不同的认识，最后设计出来的领域模型也完全不同。所以，我们发现，当我们在做DDD领域驱动设计时，往往每个人最后设计出来的领域模型是不同的，因为每个人对同一个领域的问题的本质理解不同。甚至可以说，这个是每个人的世界观的不同导致。虽然这样，但DDD的最大价值在于会要求我们主动去思考领域，思考如何用模型，从OO的角度去思考问题，思考状态的一致性维护，状态变化的规则，等。相比传统数据库驱动的方式、面向过程的方式，脑子里只有数据结构、关系、以及过程。没有对象、交互、职责这方面的思考意识。
我承认，这个领域模型的设计确实不错，甚至更好！但我们不能说，前面的领域模型的设计（帖子包含标题和内容、回复只有内容）是错误的，因为只是对领域问题的不同理解而已。前面的领域模型的设计，也是自然合理的，我认为。
当然，讨论回来，在DB层面，不管领域模型如何设计，我们在更新帖子统计信息时，还是会碰到并发的情况。这个其实是多用户并发回帖导致的技术问题，不是业务上的问题。技术问题就是需要通过技术手段去解决。当然，有时也可以把某些看似是技术问题的问题，提炼出合适的业务规则，通过聚合根封装业务规则，确保数据一致性的思路来解决。下面我们来看一下方案5。
方案5
基于ENode框架实现，采用CQRS架构。领域模型的设计，也是设计为帖子和回复两个聚合根。不同的是帖子中聚合了回复的统计信息，设计一个值对象，表示帖子的当前回复的统计信息。包括：最近回复的ID、作者、回复时间，以及总回复数。为什么要这样设计？因为经过对领域进一步的分析和思考，发现了领域内的一个潜在的业务规则。就是我们关心帖子的“最后”的回复信息。关键问题就是在这个“最后”两个字上。既然是最后，那就必须要知道哪个是最后，根据什么判断？就是根据回复的创建时间。然后，在高并发创建回复的时候，我们需要有一个地方，可以准确的统计出这个最后的回复是哪个。前面几个方案，要么通过DB的强一致性事务保证，要么依赖消息队列的顺序消息处理（必须依靠开发人员要处理好各种EDA的问题才行）。这些方案虽然最终却是能统计出这个最后的回复信息；但我认为，这个是属于领域内的一个业务规则；这个规则是由于我们所关心的统计信息而必须引入的。所以，更好的方案应该是用聚合根来维护这个业务规则。
所以，帖子本身可以不用聚合所有的回复信息，因为帖子本身确实不关心回复信息本身，它只是关心回复的统计信息（最后一个回复的信息以及总回复数）；因此，我们设计帖子聚合时，只需要再让其内聚一个包含回复统计信息的值对象即可。
当有一个新的回复产生后，发送一个命令，通知回复的帖子更新其统计信息；然后帖子处理这个命令时，内部判断当前回复的时间是否是最新时间，如果是，则更新最后回复信息和总回复数；如果不是，则只更新回复数。然后帖子的统计信息更新后，产生领域事件，表示帖子的统计信息有更新，然后CQRS的event handler，根据领域事件，更新读库帖子表的那几个统计字段即可；
这种方案，通过ENode提供的技术保证，可以确保消息至少投递一次，确保消息的幂等处理，以及消息（领域事件）的顺序处理，以及最重要的一点，最同一个聚合根，确保尽量做到了无并发操作；就算出现并发，也能框架层面自动重试。所以，开发人员就不用再关心这些技术相关的问题了。
个人认为，这种方案在基于ENode框架引入CQRS架构的异步思路，解决高并发的问题的同时，进一步挖掘了业务需求，分析出了潜在的业务规则，通过用聚合根来维护这个业务规则，最终确保了数据的最终一致性；缺点是，依赖了ENode框架。对我个人来说，肯定是最喜欢这种方式，呵呵。目前enode forum案例，就是采用这种方式来实现帖子的回复统计信息的维护和存储。
结束语
我觉得很多问题的解决思路都是类似的。我总喜欢使用大家都通俗易懂的案例来分析、讨论。因为只有大家对这个业务都比较理解，才具有讨论的基础。另外，我相信每个人都有举一反三的能力。一旦我们把某个业务问题分析清楚，那也许遇到其他类似的业务问题时，我们曾经的业务问题分析经验会帮助到我们，从而可以更加快速的理解和解决相似问题领域。这也是我为什么要花精力写出这么多方案的原因。多思考一点，多深入一点。自己就会多成长一点，对未来的领域问题的分析就会更快速一点。
