DDD-使用聚合的瞬态验证

本文关键字：验证 DDD- | 更新日期: 2024-10-22 02:57:02

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

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

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

我有什么选择可以使用DDD更好地工作？我曾考虑将其分离为域服务。任何建议都将不胜感激！

DDD-使用聚合的瞬态验证

通常情况下，聚合不应该公开Get-方法，您总是希望遵循Tell Don’t-Ask原则。如果需要完成，那么您调用一个聚合方法，它就会完成。

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

经验法则是：

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

在你的情况下，据我所知，你只需要验证用户的输入，所以你不需要麻烦你的域来做这件事，原因有两个：

  1. 您不做任何事情，也不更改系统的状态。它被认为是一个"读取"操作，直接执行（调用服务、根据一些表进行验证等）
  2. 您不能依赖验证结果。现在它告诉你"正确"，10毫秒后（当你通过网络得到响应时，当HTML在浏览器中呈现时，等等）它已经是历史了，它可能随时改变。因此，这种验证只是一种指导，不再是了

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

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

相关文章：