web-dev-qa-db-ja.com

検証に仕様パターンを使用するDDD

検証の目的で仕様パターンを使用することを考えています。難しいのは、一部の仕様が満たされていない理由をユーザーに伝える方法です。 Specification.IsSatisfiedBy()がbool値だけでなく、失敗の理由も返す場合はどうなりますか。次のようになります。

interface ISpecification<T>
{
  CheckResult IsSatisfiedBy(T candidate);
}

ここで、CheckResultは次のとおりです。

class CheckResult
{
  public bool IsSatisfied { get; }
  public string FailureReason { get; }
}

Fowler＆Evans の作業には、部分的に満足した仕様の概念があり、その目的は、正確に満たされていないことを説明することです。ただし、そのドキュメントでは、Candidateによって達成されなかった仕様を返す追加のメソッドremainderUnsatisfiedByとして実装されています。

したがって、問題は次のとおりです。検証の目的で仕様を使用する場合、特定の仕様が満たされていないというフィードバックをユーザーに提供するにはどうすればよいですか。私が上に提示した解決策は良いですか？

domain-driven-design
22
Markus

検証に仕様クラスを使用することもできますが、ドメイン内で個別の概念として保持することをお勧めします。同じ基本仕様を再利用する必要があるが、目的とコンテキストに応じて異なる「失敗の理由」を返す必要がある場合があります。詳細については、 この記事 を参照してください。

上記の投稿の作成者も、コードをgithubに共有し、コードをNCommonとして投稿しました。特にこれらの領域を確認してください。

仕様： https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Specifications

検証： https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Rules （特にValidationResultおよびValidationErrorのクラス）

19
Chris Melinn

私も同じ問題を抱えていました。仕様の検証デコレータを作成します（コードは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);

  }
5
user1297783