在尝试使用事件外包时，我试图从CQRS模式的命令端的聚合实体了解验证。
基本上，我想知道处理验证的最佳实践是： 1.说代码的唯一性。 2.永恒聚合ID的正确性/有效性。
我最初的想法： 我曾考虑过构造函数会传入服务，但这似乎是错误的，因为实体的“创建”应该是要分配的值。
我曾考虑过在聚合之外进行验证，但这似乎把逻辑放在我认为应该由聚合本身负责的地方。
有人可以在这里给我一些指导吗？
答案 0 :(得分：1)
说出代码的唯一性。
确保唯一性是set validation的特定示例。集验证的问题是，实际上，您是通过锁定整个集来执行检查的。如果整个集合都包含在单个“集合”中，则很容易做到。但是，如果集合跨越了聚合，那就有点混乱了。
唯一性的常见解决方案是在数据库级别进行管理。 RDBMS确实擅长设置操作，并且可以有效地序列化。不幸的是，这将您锁定在具有良好集支持的数据库解决方案中-您无法轻松切换到文档数据库或事件存储。
有时合适的另一种方法是针对可用代码的缓存副本对唯一性进行一次汇总检查。这为您提供了更多选择存储解决方案的自由，但同时也使数据争用引入了您要避免的重复项。
在某些情况下，您可以将代码唯一性编码为集合的标识符。实际上，每个标识符都是一组标识符。
请记住格雷格·杨的问题
发生故障会对业务产生什么影响？
知道失败的代价是多少，这可以告诉您很多有关解决问题的费用。
永恒集合ID的正确性/有效性。
通常分为两部分。比较容易的一种方法是根据某些已约定的模式来验证数据。如果我们同意标识符将为URI，那么我可以验证我收到的数据确实满足该约束。同样，如果标识符应该是UUID的字符串表示形式，则可以测试我收到的数据是否与RFC 4122中所述的验证规则匹配。
但是，如果您需要检查标识符在其他地方是否正在使用 ？然后，您将不得不问...。在这种情况下，主要问题是您是否需要立即解决该问题的答案，或者是否可以异步检查（例如，通过对“未验证的标识符”和“验证的标识符”）。
当然，您再次可以调和分布式计算中固有的所有竞争。
没有魔术。