java - 如何创建 ddd 聚合并在同一事务中使用其引用更新其他聚合？

Question

我想问一下我在实现游戏时使用DDD时遇到的问题。

我遇到一种情况，根据系统收到的消息，为玩家创建一个新的聚合。问题来自于这个新聚合必须由另一个聚合(表聚合)使用其 id 引用。第二个聚合保存一个值对象，其中包含有关牌 table 上玩家的信息，例如他的位置或选择的颜色。玩家聚合存储玩家操作，因为根据玩家数量和他们发出的操作，表聚合可能会变得巨大，并且如果我将所有内容都保留在表上，数据库中的锁争用成本将太高。为了让玩家能够加入 table ，必须首先通过一些验证，例如未采用颜色、已达到最大玩家数量或玩家已处于不活动状态的游戏，这就是为什么此值对象与信息一起存储在表中来自玩家。

因此，基于此，我仅在玩家发出第一个要存储在表外的操作时创建玩家聚合。问题在于，表可以保存引用尚未创建的聚合的值对象，这使得代码看起来很难看，因为它强制它检查空引用。另一个选项，即首先创建玩家聚合，也会破坏设计，因为创建玩家的验证首先发生在 table 上。由于系统的并发性质，首先在表上进行验证，然后创建玩家聚合，然后在接收来自创建的事件时更新表，可能会导致许多竞争条件。我唯一能想到的是在同一事务中更新两个聚合，但这违反了 DDD 规则。

有什么好的解决办法吗？我想最终这将与设计有关，但我想不出有什么方法可以在不引入性能问题的情况下工作。

谢谢。

Answer 1

通常，您的部分问题可以通过从领域和通用语言的角度来看待来解决。

• Udi Dahan 有一个 excellent article关于聚合根不是凭空出现的，而是作为域操作的结果，该域操作必须是一流的普遍语言公民。在您的情况下，Player 可能不是由应用程序服务创建的，而是由 Table AR 创建的，最接近域源。

  请注意，我不一定主张像 Udi 的示例那样保留对其他根的完整引用，但您可以用 Table.ReceivePlayer(...) 返回新创建的播放器来替换它，这然后可以通过应用程序服务将其添加到 PlayerRepository 中。由于 Player 不扮演聚合根的角色(即修改和不变执行的单个入口点)，而是在该场景中扮演简单实体的角色，因此您可以合法地将所有这些包装在单个事务中.

• 驱动聚合建模的力量基本上是真正的不变量、并发性和性能。为了证明您的建模方式是正确的，您声明表聚合可能会变得巨大，并且如果我将所有内容都保留在表上，数据库中的锁争用成本将会太高。

  我认为，进一步探索这个争论到底是什么，并将领域术语放在它后面，丰富你的无处不在的语言，将会是值得的。表是大规模并发的吗？为何如此 ？游戏是否具有可供玩家修改的可变共享状态？玩家是否需要根据其他玩家的行动做出决定，如果同时采取并发行动，则会引入某种偏见？所有这些如何转化为领域术语？额外的 Player 聚合会给您带来什么？

  就性能而言，大规模 Table 聚合会是什么样子？它将如何影响系统？

• “没有事务跨越多个聚合”规则只是将聚合作为一致性边界的必然结果，它并不是一成不变的。制作小型的、独立一致的聚合并在单个事务中对其中的多个聚合进行大量修改是没有意义的，因为您会创建不必要的争用，并随之而来潜在的并发问题。但是，在除了唯一的 Table AR 之外不存在并发问题的情况下，创建肯定就是这种情况，因为没有其他人知道添加了 Player，就好像您仅修改了一个聚合，并且该规则不再真正成立。

  如果您在 99% 的修改情况下遵守规则，但在 1% 的创建情况下不遵守规则，那么您仍然在排队。