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. 事件版本控制

如果这两个优势中的任何一个对您的应用程序有帮助，您可以自行决定。