DDD Using Specification pattern for Validation

Question

I am thinking of using Specification pattern for validation purposes. The hard thing is how to tell the user why some Specification was not satisfied. What if the Specification.IsSatisfiedBy() will not only return a bool value, but also the reason of failure. It would look something like this:

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

where CheckResult is:

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

In Fowler & Evans work there is a concept of Partially Satisfied Specification whose purpose is to provide explanation what exactly was not satisfied. However in that document, it is implemented as additional method remainderUnsatisfiedBy which returns the Specification which was not accomplished by the Candidate.

So the question is: When using Specification for validation purposes, how to provide feedback to user that a given Specification was not satisfied? Is the solution I've presented above good?

Congest

First of all, are you really sure that Specification is the way to go? I mean, does each specification knows the context where a model might be or not valid? I can't say much since I don't know what the domain looks like. For some simple validation I think it's ok, but that's what DataAnnotation validation attributes are doing right now. – Kweisui

Answer 1

Although you may use your Specifications classes for validation, I would suggest you keep them as separate concepts within your domain. You may find that you need to re-use the same underlying specifications but need to return different "Failure Reasons" depending on purpose and context. See this article for more details.

The author of the post referenced above has also kindly shared code to github and posted the code as NCommon. Review these areas in particular:

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

Validations: https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Rules (especially the classes for ValidationResult and ValidationError)

Alicia

Answer 2

I had the same problem. I create Validation decorator for Specification (code is 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);

  }

Chemash

Answer 3

Not sure about your language, but in Scala there is a concept (structure): Either[A,B]

And in calculations you either return right side (B) - for successful validation (object satisfy business rule) or left side (A) to express reason of failed validation for a given business object.

For the Specification purpose, you could return (for A type) e.g. String (as an error message) or some objects/enums (or anything which is appropriate in your language) representing business reason of why specified object didn't satisfy the specification.

It's similar to your solution but more functional and robust.

Bark