DDD検証のための仕様パターンの使用

Question

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

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

目的を正確に満足していなかったものを説明を提供することである部分的に満足仕様の概念があります：CheckResultがある

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

：それは次のようになります。しかし、その文書では、追加メソッドremainderUnsatisfiedByによって実装されています。これは、候補者によって実行されなかった仕様を返します。。

質問：検証の目的で仕様を使用する場合、指定された仕様が満たされていないというフィードバックをユーザーに提供する方法を教えてください。私が上に提示した解決策は良いですか？

Answer 1

検証のために仕様クラスを使用することもできますが、ドメイン内で個別の概念としてそれらを保持することをお勧めします。同じ基本仕様を再利用する必要がありますが、用途や状況に応じて異なる「失敗理由」を返す必要があることがあります。詳細はthis articleを参照してください。

上記の投稿の著者は、親切にgithubのコードを共有し、コードをNCommonとして投稿しました。特に、これらの領域を確認します。

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

検証：私は同じ問題を抱えていた

Answer 2

https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Rules（ValidationResultとValidationErrorをに特にクラス）。仕様（コードは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); 

    }