domain-driven-design - 我应该在哪里检查 ddd 架构中的唯一性

Question

在我的域模型中，我有一个客户聚合根。我的业务规则是 -> 我不能添加具有相同名字、姓氏和电子邮件地址的新客户。这种验证检查的最佳地点在哪里？

首先，从我的角度来看，将这种支票放在我的客户集合中是完全错误的。 其次，在我的 CustomerRepository 中添加此验证也感觉不自然，因为我想在内存集合中将它们视为简单，并且我的所有聚合的逻辑基本相同。 第三，我也不打算在我的 CreateCustomer-Command 中添加这个检查，因为这个重要的检查不在我的域模型之外。

所以我看到的最后一个选项是创建一个 CustomerService 类并将这种验证放在这里。

你还有什么建议吗？我已经阅读了许多其他帖子，但他们并没有真正给出明确的答案......谢谢！

标签： domain-driven-designddd-repositoriesddd-service

Answer 1

您所描述的问题的通用术语是set validation。

如果业务可以接受在短时间内违反不变量，那么您建立一个流程来监视所有客户聚合以查找冲突，并在发现冲突时通知一些补救流程。您可以通过将先前条目的检查合并到您的业务逻辑中来降低（但不能消除）冲突的风险；在数据竞争中仍然有可能违反约束。

如果这样做是不可接受的（也许法律或财务影响太严重），那么事情就会变得更加困难。

有时可行的一个答案是获取必须唯一的值，并使用这些值生成聚合的唯一标识符。不幸的是，名字、姓氏和电子邮件地址不够稳定，无法成为该方法的良好候选者（如果您的客户更改其电子邮件地址或法定名称会怎样？）

当您对其中一个客户进行修改时，这会锁定整个客户群。这可能就像强制任何要修改客户的进程获取共享锁一样简单，或者将所有客户放入单个聚合中，或者将约束编程到您的存储中（想想 RDBMS 中的约束）。