如何处理DDD / CQRS中的硬聚合范围约束？

如何解决如何处理DDD / CQRS中的硬聚合范围约束？

我是DDD的新手，我试图基于DDD，CQRS和事件源来建模和实现一个简单的CRM系统，以体会这种范例。但是，我遇到了一些不确定的问题，我不确定该如何处理。我不确定我的困难是由于我没有正确地对域进行建模还是由于缺少其他东西而引起的。

对于我的问题的基本说明，请考虑我的CRM系统具有汇总CustomerAggregate（在我看来是合理的）。这种汇总的目的是确保每个客户都是一致的，并确保其invarints保持不变（姓名是必需的，社会保险号必须使用正确的格式，等等）。到目前为止，一切都很好。

但是，当系统收到创建新客户的命令时，它需要确保新客户的社会保险号尚不存在（即，它在整个系统中必须是唯一的）。当然，这不是CustomerAggregate聚合可以强制执行的不变式，因为客户没有关于其他客户的任何信息。

我看到的一个建议是在其自身的集合中处理这种约束，例如SocialSecurityNumberUniqueAggregate。如果尚未在系统中注册社会安全号码，则SocialSecurityNumberUniqueAggregate发布SocialSecurityNumberOfNewCustomerWasUniqueEvent订阅的事件（例如CustomerAggregate），并为此发布自己的事件（例如CustomerCreatedEvent）。这有意义吗？ CustomerAggregate在响应SocialSecurityNumberOfNewCustomerWasUniqueEvent时将如何响应，例如缺少名称或其他严格的约束？

解决方法

您要搜索的搜索词是set-validation。

如果您可以将整个集合放入单个数据库中，则关系数据库确实非常擅长域不可知集合验证。

但是，这是有代价的。以这种方式设计模型会限制您在可以用作记录簿的数据存储类型方面的选择，并将“域逻辑”分为两个不同的部分。

另一种常见选择是在运行域逻辑时忽略冲突（毕竟，此约束的业务价值是什么？），而是监视持久化数据以查找潜在冲突并在似乎有问题的情况下升级为人类。

您可以将两者结合起来（例如：在运行域逻辑时通过查询检查是否存在重复项，并在以后监视结果以减轻数据争用）。

但是，如果您需要在集合上维护不变性，并且需要将其作为写模型的一部分（而不是分离到持久层中），那么在进行更改时就需要锁定整个集合。 / p>

这可能意味着拥有一个“ SSN分配注册表”，这是其自身的汇总，您必须开始考虑需要将多少其他客户数据纳入该汇总中，以及可以使用多少其他汇总数据通过通用标识符，当通过不同的锁来控制数据集时，可能会出现所有可能的复杂情况。

没有规则说所有客户数据都必须属于一个“集合”；参见毛罗·瑟维文（Mauro Servienti）的演讲All Our Aggregates are Wrong。权衡比比皆是。

---

您要在建模中非常小心的一件事是将数据输入验证与域逻辑相混淆的风险。除非您正在为社会保障局编写域模型，否则SSN分配不受您的控制。您的模型具有的是缓存副本，在这种情况下，则可能是损坏的副本。

例如，考虑一个声明以下内容的数据集：

000-00-0000 is assigned to Alice
000-00-0000 is assigned to Bob

显然存在冲突：如果社会保障管理部门维持唯一的任务，那么这两种说法都是不正确的。但是，在其他所有条件都相同的情况下，您无法确定其中哪些主张是正确的。尤其是“您首先要写下来的声明必须是正确的”这一建议并没有太多的逻辑支持。

在这样的情况下，通常会推迟自动判断，而将问题转嫁给人类来处理。

尽管它们在很多方面在机械上都是相似的，但是“我们的标识符分配的集合应该没有冲突”和“已知的第三方标识符分配的集合应该没有冲突”之间有重要的区别。

,

您还需要验证社会安全号码（SSN）确实有效吗？还是您只是想验证您的CRM系统中是否不能创建具有相同SSN的其他客户集合？

如果是后者，我建议您使用一些 CustomerService domain service ，通过查看来执行整个SSN检查（例如通过存储库）建立数据库，然后创建新的客户集合（如您已经提到的，它再次检查它自己的不变量）。这整个过程-查找现有的SSN和创建客户-必须在一次交易中 进行，以确保一致性。我认为域逻辑是域服务的理想之选。它不会单独保存数据，但会编排与业务需求相关的工作流-无需在我们的CRM中创建具有相同SSN的客户。

如果您还需要 验证 该身份证号是真实的，则还需要执行一些我猜想的另一项服务或保留一些SSN缓存数据在您的CRM中。在这种情况下，您可以另外添加一些 SocialSecurityNumberService 域服务，并将其注入 CustomerService 中。这只是域层中的接口，但是此SocialSecurityNumberService接口的实现将驻留在基础结构层中，在该基础结构层中实现对所需资源的访问（无论是在后台构建的本地缓存还是对另一个API的一些调用）服务）。

无论哪种方式，创建新客户的所有逻辑都在一个地方，即 CustomerService 域服务 。超出 Customer汇总边界的其他检查也将放置在此 CustomerService 中。

更新

还要遵守最终一致性的性质：

我想在进行事件采购时，您和您的企业已经接受了最终一致性性质。这也意味着具有相同SSN的条目可能会发生。我认为您可以进行一些后台工作，以不断检查重复项，并且根据业务逻辑的复杂性，您可能能够自动更正重复项，或者需要人工干预才能执行此操作。这真的取决于这种情况多久会发生一次。

如果一个严格的约束条件是这种 绝不能发生 ，那么事件源不是正确的方法，至少对于系统的这一部分而言……

注意：我还假设命令重复数据删除不是这里的问题，但是您实际上必须使用同一SSN处理可能不同的命令。