I’ve often pondered the use of specifications when validating objects to keep my code DRY – a nice approach i’ve come across recently is demonstrated here: http://www.goeleven.com/blog/entryDetail.aspx?entry=59 The author extends a common implementation of the specification pattern to also include the ability to determine the unsatisfied part of the specification – returning the unsatisfied part as a specification itself. Good stuff! I can imagine it would be relatively painless to extend this to derive user-friendly failure reasons.

1. To validate an object to see if it fulfills some need or is ready for some purpose
2. To select an object from a collection (as in the case of querying for overdue invoices)
3. To specify the creation of a new object to fit some need

I mostly use it for #2. I could see using specs for #1, but I would still want the feedback part of knowing “why”. Specs are great for “if”, but I think I’d rather separate validation specs into new “IValidationSpec” interface that also gave me failure reasons.

That is an interesting approach though, I’ll have to keep it in mind. Just when you thought you knew the Evans book inside and out…

At least that’s my take on it…
BTW = Jeff Perrin did a great post on Specifications a while back: http://devlicio.us/blogs/jeff_perrin/archive/2006/12/13/the-specification-pattern.aspx

From a high level my understanding is that the Specifications impose Ubiquitous predicate constructs in relation to Entity validation.

Suppose during a dialog with the product owner, they inform you that for an order to be valid, that is has to be ordered as of a specific date and not be over a certain amount.

I would then pose the question could we refer to this rule set as the “BasicOrderSpecification” ? Usually they say sure or we change the nomenclature to be more expressive for them. Now we have a common “Ubiquitous” term for dealing with the business rules in determining if an order is valid.

Anytime I bring up the term “BasicOrderSpecification” the team (product owner, developer and QA) knows that I am referring to, must meet a certain ceiling amount and enforce this date rule.

Order order = new Order();
if (BasicOrderSpecification.IsOrderValid(order)…

Aside from my banter, Great post! That is exactly how I model my Specifications but not how I utilize them.