在哪里验证唯一的AggregateRoot-属性？

Question

我有一组“大”的AggregateRoots，它的属性在其上下文中应该是唯一的。但是我在哪里验证这个呢？我想这取决于上下文是什么，在我看来，我有两个选择：

要么我在存储库服务中实现验证，这样持久化逻辑就可以在保存聚合之前验证唯一的属性(然后还必须同步这个AR类型的所有保存)。

或者，我将“唯一索引”作为聚合引用的字典移到另一个聚合中，让该字典验证惟一的属性。由于我有一组非常大的AR，这种方法可能会有问题，如果没有实现，那么索引就可以尽可能多地保存在磁盘上。

但是这里有真正的赢家吗？这两种方法都有效且安全吗？有什么主要的缺点需要考虑吗？其他变体？

我的想法：

第一种方法可能比较简单，但也比较有限。例如，如果需要的话，为同一AR类型设置多个索引就更复杂了。另一种方法更本地化于单个聚合，这与应该如何处理聚合更加一致。第一种方法要求由同一进程保存此类型的所有聚合，因为所有保存都必须是同步的。另一种方法不需要这样做，而是引入了这个索引聚合，为了验证属性上的新值和更新值，必须传递所有保存的索引聚合。此方法也不验证数据库中是否存在具有相同属性值的多个聚合，只验证引用的聚合具有唯一属性。

Answer 1

聚合只关心其自身的一致性。它并没有真正的兴趣--它与系统中的其他任何事物有何关联或关联，超出了它自己的界限。

如果您需要做任何交叉聚合检查，有两个选项--要么您需要重新考虑您的聚合边界，要么您当前的聚合只是一个更大的聚合的实体。但是，如果您的事务范围是您当前作为聚合的范围(尽管唯一性约束在某种程度上与此语句相矛盾)，它将无法工作。

但我们都知道一些事情，比如臭名昭著的独特的用户名悖论。很明显，整个用户不能是一个单一的聚合，但您需要确保用户名是唯一的。解决方案是在应用程序服务中检查唯一性，甚至在进行聚合之前。如果您的查询存储是完全一致的，它应该不会是一个问题。如果您的写入和读取侧不能保证同步，则仍然可以使用读取侧来确保唯一性，同时考虑到违反此约束的可能性。如果没有大爆炸，没有小猫会死，你可能会接受这样的情况，并处理约束的违反，当它实际发生，这可能永远不会。