我有一个聚合根，它是一个拣货和打包订单的计划。它将被分配一个托架，并且该托架必须是空的。
我将创建一个名为 AllocateToBay 的命令，该命令将指示应使用哪个托架。但是我应该如何从订单内部验证托架实际上是空的？
我在想我需要的是一个bay聚合根，我需要让bay将自己分配给订单。然后它可以引发一个事件，说它被分配给一个订单。然后我可能会有一个 saga 来监听这个事件，然后向命令发出命令，让它知道它也被分配了哪个托架。但是，我真的不觉得海湾应该是聚合根。
或者，我可以只“信任”该命令，并拥有一些监视事件以检测重复分配的东西，并且它可以发出一个命令来纠正任何重复分配（我猜这仍然是一个传奇）？这样，bay 至少不必是聚合根。
这一切似乎有点冗长，但我想不出更好的方法来做到这一点？
【问题讨论】：
标签： cqrs
如果聚合根需要从自己的边界之外查找数据，通常的答案是传入支持查询的服务提供者（即域服务）。
但是，我真的不觉得海湾应该是聚合根。
Bay 是现实世界中的一个东西，对吧？那么它就不是聚合根，因为控制海湾的“状态”的是现实世界，而不是您的模型。
或者，我可以只“信任”该命令，并拥有一些监控事件以检测重复分配的东西，它可以发出命令来纠正任何重复分配
鉴于您正在处理不受域模型控制的状态的验证，因此您的模型总是存在根据有关海湾状态的陈旧和不准确信息做出决定的风险。所以检测潜在的冲突（记住，你的检测器也在处理陈旧的数据）并且升级可能很重要。
也就是说，您的模型应该只分配给它认为可用的托架是合理的；特别是如果模型更可能具有更新的信息，或者如果海湾的选择应该是聚合状态的一部分。
您是否希望人工操作员能够在集合体的模型显示托架被占用时坚持让集合体将工作分配给托架？这个用例可能决定了聚合是检查还是信任命令。
您认为正在监视许多不同的事件，检查冲突，可能是“流程管理器”，而不是 saga（这是在长时间运行的事务中使用的更复杂的东西；那里有很多写作这混淆了这两个术语）。
【讨论】：