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?
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.
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.
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.
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)
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); }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With