DDD： - 如何对概念及其历史进行建模？

Question

我们有一个名为 SignupRequest 的汇总，我们需要跟踪此汇总历史记录，例如请求被接受或禁止或类似的东西。 您更喜欢哪种解决方案来模拟这些业务概念？ 1-我们创建一个 signupRequestHistory 聚合，用于管理signupRequest的历史记录？ 2- SignupRequest 将包含 SignupRequestHistory 值对象的集合。

• 请记住，SignupRequestHistory只是一个跟踪历史记录（不可变数据） 对于请求本身。这些历史数据不存在业务不变量
• 此外，在许多地方应用了相同的概念： - 例如，Subscriber和SubscriberHistory因此，我们需要一个干净的模式来实现该功能
• 此外，历史记录仅用于报告目的

Answer 1

正如您所提到的，您可以创建一个SignupRequestHistory聚合，其中包含SignupRequest的状态以及更改的日期/时间。

  

SignupRequest将包含SignupRequestHistory值对象的集合。

在向SignupRequest添加馆藏之前，您需要考虑为什么要这样做。您指定“不存在业务不变量”，这是SignupRequest可能不需要SignupRequestHistory集合的第一个指示。

我不知道您确切的域名，但SignupRequestHistory可能不是其中的一部分。它不用于解决任何业务问题，严格用于报告/视觉需求。 SignupRequestHistory真正代表的是域事件 - 域中的状态更改。这让我相信你会从事件采购中受益。

使用事件源所有域事件时，聚合根加注按顺序存储在事件存储中。无论何时更改聚合的状态，都会引发一个事件，该事件将被存储以备将来使用。这将为您提供聚合根所处的所有不同状态的历史记录。您可以通过从事件存储中按顺序读取事件（事件流）到历史记录中的任何日期/时间来重建聚合根，以查看聚合根目录在历史上看起来像那个时候。

对于报告需求，您可以使用各种存储的域事件构建高效的视图模型。

事件采购可以预先做很多工作。如果你没有很多时间可能会采用第一种方法是最好的。每种方法都有利弊。你应该在业余时间考虑事件采购。

Answer 2

我建议再次完善你的有界上下文边界，也许这段历史应该保存在另一个有限的背景中。

您可以尝试使用CQRS并通过侦听写模型（聚合）发出的相关域事件来创建包含所有聚合状态历史记录的特定读取模型。

虽然Event sourcing很棒但是不适合这种情况。它只是为了从实体历史中受益而有太多的开销。

<强>更新

事件采购比普通CQRS有两个主要优势：

1. 您不需要使用交易
2. 您可以根据需要添加任意数量的阅读模型

它还有一个大减去：

1. 事件版本控制

如果这两个优势中的任何一个对您的申请有帮助，那就是您的电话。