域服务的域模型中的验证？答案

【问题标题】：Validation in Domain Model of Domain Service?域服务的域模型中的验证？
【发布时间】：2016-03-11 07:39:02
【问题描述】：

我正在阅读“为企业构建应用程序 (Dino Esposito)”一书。它提出了一个关于验证的问题。

领域模型可以有一个属性 CanBeSaved，它调用领域模型的 Validate() 方法。一切都很好，除了复杂的情况。例如，需要唯一客户代码（例如 000542）的客户模型。您只能通过数据库访问来检查这一点。将验证始终放在域服务中不是更好吗？所以你只有一种方法可以检查聚合是否处于有效状态？如果您同时使用两者，开发人员可能会“忘记”为客户使用域服务验证。

【问题讨论】：

当您提到域服务时，您实际上是指应用程序服务。域服务与数据库或外部基础设施无关。如果您想将外部验证逻辑放入应用程序服务中，这可能是一种实用的方法。我不完全理解您关于“忘记使用验证”的开发人员的说法。如果您的应用程序服务是创建聚合的唯一方法，那么任何人怎么能“忘记”这样做呢？

标签： validation domain-driven-design

【解决方案1】：

我发现拥有always valid 实体比依赖外部验证对象更好。

话虽如此，唯一检查有点例外，因为它通常不是聚合本身可以自行确定的，您必须查看所有现有聚合以查看该值是否尚未被采用。我所做的是在创建实体之前检查值的可用性，并在数据库中放置一个约束，这将在持久性时验证唯一性。您还可以尝试找到一个包含所有实体的域概念，并使其成为具有所有代码列表并强制唯一性不变量的聚合。

【讨论】：

如果你总是这样做的话，之前检查可用性是一个很好的选择。您的 UI 可以用新的唯一值预填充它。问题与身份证号码、银行帐号、社会保险号码相同......
当然。唯一检查在 DDD 中是一个非常开放的问题。如果你真的希望它在任何时候都立即保持一致，你绝对应该尝试找到一个总体概念并将其作为一个聚合来验证所有Customercodes 的唯一性。 codes 和 Customer 创建的更改都应该通过该聚合。如果最终一致性是一个选项，您还可以拥有一个订阅CustomerCreated 事件并在检测到code 冲突时采取补偿措施的应用程序服务。但这意味着放弃数据库中的唯一约束
“问题与...相同” - 谨防看似常识的笼统陈述。如果您与您的领域专家交谈，通常会发现很多东西。实际上，在您的域中，您可能会同时需要其中两个具有相同值的东西。