domain-driven-design - 单个命令应该处理多个聚合吗？

Question

在 CQRS 和 DDD 中，聚合是事务边界。因此，我一直以这样的方式对命令进行建模，即每个命令始终只处理一个聚合。当然，从技术上讲，可以编写处理多个聚合的命令处理程序，但这不会在单个事务中，因此不会保持一致。

如果您实际上必须处理多个聚合，我通常会选择流程管理器，但这有时感觉开销很大。此外，根据我的理解，流程管理器总是只对域事件使用react，而不是由命令直接解决。因此，您需要决定将起点放在哪个聚合上。

我看到有些人使用所谓的域或应用程序服务来解决这个问题，它们也可以接收命令，然后在多个聚合上工作——但在这种情况下，过程的事务性质就丢失了。

举个简单的例子，更好的说明场景:

• 用户应加入一个组。
• 一个用户有最大数量的组。
• 一个组有最大用户数。

将触发初始加入过程的命令放在哪里，如何调用它？ user.join(group) 感觉和 group.welcome(user) 一样对或错。我可能会选择第一个，因为它更接近于无处不在的语言，但无论如何……

如果我在聚合之上有一些东西，比如前面提到的服务，那么我可以运行一些东西，比如:

userManagement.addUserToGroup(user, group);

但是，此 addUserToGroup 函数随后需要调用这两个命令，这反过来意味着它必须处理正在处理的两个命令——这与完全分开聚合有点违反直觉，并且将聚合作为事务边界。

对此建模的正确方法是什么？

Answer 1

可能值得在 Eventual Consistency and Set Validation 上回顾 Greg Young .

What is the business impact of having a failure

This is the key question we need to ask and it will drive our solutionin how to handle this issue as we have many choices of varying degreesof difficulty.

当然还有 Pat Helland 的 Memories, Guesses, and Apologies .

简短版:两位将军告诉我们，如果两条信息必须一致，那么我们需要将两条信息写在同一个地方。 “不变量”约束了我们的数据模型。

你描述的不变量实际上是几个集合验证问题:“成员资格”集合只允许这么多的用户 A 成员，只有这么多的组 B 成员。如果你真的在“我们出去如果违反了这些规则”的情况，那么你不能分发那个集合的成员——你必须在修改它时锁定整个集合以确保规则没有被破坏，并且首先作家获胜。

在您的建模中需要注意的一个元素:域模型是成员资格的权威吗？还是“现实世界”负责成员资格，而域模型只是缓存该信息以备后用？在尝试对现实世界强制执行不变量时，您需要非常小心。

存在过度限制模型接受信息的顺序的风险。