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

Question

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

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

或者我将另一个聚合中的“唯一索引”作为聚合引用的字典移动，并让该字典验证唯一属性。由于我有大量的 AR，如果不实施这种方法可能会出现问题，以便索引可以尽可能多地保存在磁盘上。

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

我的想法：

第一种方法可能更简单一些，但也更受限制。例如，如果需要，为同一 AR 类型拥有多个索引会更加复杂。另一种方法更本地化为单个聚合，这更符合我猜应该如何处理聚合。第一种方法要求所有这种类型的聚合都由同一进程保存，因为所有保存都必须同步。另一种方法不需要这个，而是引入这个索引聚合，所有保存都必须通过它来验证属性上的新值和更新值。此方法也不会验证数据库中是否存在多个具有相同属性值的聚合，仅验证引用的聚合具有唯一的属性。

Answer 1

聚合只关心自己的一致性。它实际上并不关心它如何与系统中的任何其他事物相关或相关，在它自己的边界之外。

如果您需要进行任何交叉聚合检查，有两种选择 - 要么您需要重新考虑聚合边界，要么您当前的聚合只是更大聚合的实体。但是，如果您的事务范围是您当前作为聚合的范围，则它将不起作用（尽管唯一性约束与此陈述相矛盾）。

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