DDD使用规范模式进行验证

Mar*_*kus 22 domain-driven-design

我正在考虑使用规范模式进行验证.困难的是如何告诉用户为什么某些规范不满意.如果Specification.IsSatisfiedBy()不仅会返回一个bool值,而且还会失败的原因怎么办?它看起来像这样:

interface ISpecification<T>
{
  CheckResult IsSatisfiedBy(T candidate);
}
Run Code Online (Sandbox Code Playgroud)

在哪里CheckResult:

class CheckResult
{
  public bool IsSatisfied { get; }
  public string FailureReason { get; }
}
Run Code Online (Sandbox Code Playgroud)

Fowler&Evans的工作中,有一个部分满足规范的概念,其目的是提供解释究竟不满足的内容.但是在该文档中,它被实现为附加方法remainderUnsatisfiedBy,它返回候选者未完成的规范.

所以问题是:当使用规范进行验证时,如何向用户提供不满足给定规范的反馈?我上面介绍的解决方案是否合适?

Chr*_*inn 19

虽然您可以使用规范类进行验证,但我建议您将它们作为域中的单独概念.您可能会发现需要重复使用相同的基础规范,但需要根据目的和上下文返回不同的"失败原因".有关详细信息,请参阅此文章.

上面引用的帖子的作者也亲切地与github共享代码并将代码发布为NCommon.特别审查这些领域:

规格:https: //github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Specifications

验证:https: //github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Rules(特别是ValidationResultValidationError的类)

  • codeinsanity的示例看起来像FluentValidation :) (2认同)

use*_*783 5

我有同样的问题.我为Specification创建了Validation装饰器(代码是JAVA).

  interface Validator<T>{
    Respond validate(T t)
  }


  class abstract ValidationSpecificationDecorator<T> implements Validator<T> {
  Specification<T> spec;

  ValidationSpecificationDecorator(Specification<T> spec){
    this.spec =  spec;
  }

  public Respond  validate(T t) {
    Respond respond = new Respond();
    if(!spec.IsSatisfiedBy(t){
       respond.add(error(t));
    }
    return respond;
  )

  public abstract Error error(T t);

  }
Run Code Online (Sandbox Code Playgroud)