oop - ddd 中的验证方法

Question

我对 ddd 中的验证方法有疑问。我已经阅读了相当有争议的意见。有人说这应该在实体之外，其他人说这应该放在实体中。我试图找到一种我可以遵循的方法。

例如，假设我有带有电子邮件和密码的 User 实体。用户有一个方法注册(电子邮件，密码)。电子邮件和密码验证应该放在哪里？我个人的意见是它应该在 Register() 方法内部。但是这种方法可能会导致 User 类与验证内容混淆。一种方法可能是在单独的策略对象中提取电子邮件和密码规则，并仍然从 Register() 方法调用它们。

您对 DDD 中的验证方法有何看法？

Answer 1

首先，我认为验证有点棘手，部分原因在于各种 contexts其中需要考虑。最终，将在各个应用层执行验证规则。至少，域对象中应该有标准的守卫。这些只是常规的前置条件和参数检查，应该是任何设计良好的对象的一部分，并且符合您对 Reigster 的看法。方法。正如lazyberezovsky 所说，这是为了防止对象进入无效状态。在这一点上，我站在永远有效的学校一边。我认为如果需要将实体保持在无效状态，应该为此创建一个新实体。

然而，单独使用这种方法的一个问题是通常需要将这些验证规则导出到其他层，例如表示层。此外，在表示层，规则需要不同的格式。它们需要一次全部呈现，并可能被翻译成另一种语言，例如 JavaScript，以便立即获得客户端反馈。尝试从类引发的异常中提取验证规则可能很困难或不切实际。或者，可以在表示层重新创建验证规则。这要简单得多，虽然可能违反 DRY，但它允许规则依赖于上下文。特定工作流可能需要与实体本身强制执行的验证规则不同的验证规则。

所描述方法的另一个问题是，可能存在存在于实体范围之外的验证规则，并且这些规则必须与其他规则合并在一起。例如，对于用户注册，另一个规则是确保电子邮件地址是唯一的。托管适用用例的应用程序服务通常会强制执行此规则。但是，它还必须能够将此规则导出到其他层，例如表示。

总的来说，我尝试对实体本身进行尽可能多的约束检查，因为我认为实体应该始终有效。有时可以设计规则框架，使其既可用于引发异常又可导出到外层。其他时候，简单地跨层复制规则更容易。