DDD - 使用聚合的瞬态验证答案

【问题标题】：DDD - transient validation using an aggregateDDD - 使用聚合的瞬态验证
【发布时间】：2013-12-18 21:10:22
【问题描述】：

我有一个特定的场景，其中聚合具有检查地址是否有效的行为。此验证通过网站上的内联 ajax 表单验证在聚合上触发。在聚合和网站之间是协调两者的应用程序服务。

就目前而言，我创建了一个本质上是空聚合的内容并设置了地址属性，以便可以完成检查。基于此，我将 true 或 false 返回到网站（ASP.NET MVC）。在 DDD 的背景下，这似乎不是正确的方法。

    public bool IsAddressAvailable(string address)
    {
        var aggregate = new Aggregate
                             {
                                 Address = address
                             };
        return aggregate.IsAddressValid();
    }

我有哪些选项可以更好地使用 DDD？我正在考虑将其分离到域服务中。任何建议将不胜感激！

【问题讨论】：

验证的性质是什么？只检查格式？根据地址数据库验证它？检查您的系统中没有注册现有地址？
所有这些。我已经简化了上面的例子。实际上，在验证过程中还会调用另一个服务。

标签： c# .net domain-driven-design

【解决方案1】：

通常你的聚合不应该暴露Get- 方法，你总是要遵循告诉-不问的原则。如果需要完成 - 然后调用聚合方法，它就会完成。

但您通常不想询问 Aggregate 数据是否有效。特别是如果您已经有一项服务可以为您完成这项工作，为什么要将这种“验证”与聚合混合在一起？

经验法则是：

如果聚合的行为不需要某些东西，则它不需要成为聚合的一部分
您只能将有效数据传递到您的域中。这意味着当您调用聚合行为要求它为您做某事时，您传递的数据已经过验证。您不想用数据验证/if-else 分支等污染您的域。保持简单明了。

在您的情况下，据我了解，您只需要验证用户的输入，因此您不需要打扰您的域来执行此操作，原因有两个：

你不做任何事情，不要改变系统的状态。它被认为是“读取”操作，直接进行（调用您的服务，针对某些表进行验证等）
您不能依赖验证结果。现在它告诉你“正确”并且在 10 毫秒内（当你通过网络获得响应时，当 HTML 在浏览器中呈现时，等等）它已经成为历史，它可能随时改变。因此，此验证只是一个指导，仅此而已。

因此，如果您只需要“只读”验证，只需针对您的服务进行验证。如果您需要验证用户的数据作为操作的一部分，那么在调用域之前执行它（可能在您的命令处理程序中）。并注意比赛条件（DB 独特的约束可以提供帮助）。

您还应该考虑阅读本文以更深入地思考集合验证：http://codebetter.com/gregyoung/2010/08/12/eventual-consistency-and-set-validation/

【讨论】：