Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

DDD Using Specification pattern for Validation

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?

like image 789
Markus Avatar asked Mar 11 '12 13:03

Markus


People also ask

What is domain in DDD principle?

Domain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.

How are domain models validated?

Implement validations in the domain model layer. Validations are usually implemented in domain entity constructors or in methods that can update the entity. There are multiple ways to implement validations, such as verifying data and raising exceptions if the validation fails.

What is the specification design pattern?

In computer programming, the specification pattern is a particular software design pattern, whereby business rules can be recombined by chaining the business rules together using boolean logic. The pattern is frequently used in the context of domain-driven design.


2 Answers

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)

like image 67
Chris Melinn Avatar answered Oct 07 '22 01:10

Chris Melinn


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);    } 
like image 43
user1297783 Avatar answered Oct 07 '22 03:10

user1297783