Validation and Domain Driven Design

I read an interesting blog post today from Justin Etheredge talking about how Validation should be handled in the context of a system using Domain Driven Design principles.

In his post, “Who knew Domain Validation was so Hard?” he talks about how putting validation code outside the domain entities seems to be the right solution, but that he has nagging doubts about the approach.

I’ve found two techniques of value in this space, Proposals and Soft Validation.

The Proposal design pattern is probably the most significant design pattern you’ve never heard of. Despite being written up in the November 1997 issue of Object Magazine (pp51-65), this pattern languishes virtually unknown.

The essence of the pattern (which I really should write up as a proper article) is that real world “changes of state” are almost always agreed upon by accepting a proposal of that change. Of course, not all proposals get accepted. A shopping cart (whether real or virtual) proposes a sale, which can be completed by successful payment or discarded; a job interview forms part of an employment proposal, where either party may discard the proposal at any time.

Proposal objects are an ideal place for validation to occur, because they are context rich, representing a very specific change of state in the system. They also provide a number of other benefits, including traceability, flexibility and inspectability – a tale for another time.

Soft Validation is the idea that validation isn’t a black or white issue – validity of a domain object isn’t a boolean value of true or false.

Consider for example the “Part Maintenance” screen of an inventory system. Changing the PartNumber of a part is a big deal – it’s the real world primary key for this kind of part. Somebody has to have an access level allowing the change to be made, because sometimes part numbers do get changed – and sometimes errors occur. But, making such a change has pretty serious consequences – anyone trying to find that part needs to know that the number has changed.

How do you validate this situation? You can’t throw an error, because the change is acceptable, but you would like to let the user know that this is an action not to be taken lightly – “Changing the Part Number of this part will impact upon future data entry and searching.”

What I’ve found to be useful is to have a range of validation levels:

• Errors – fatal issues that prevent you from proceeding further.
  “The credit card number you provided was invalid. Please enter a valid number to proceed with the sale.”

• Warnings – non-fatal issues that should be considered by the user before continuing.
  “Without a valid contact email address we will be unable to advise you of any delays with your order. Are you sure you want to proceed?”

• Hints – useful information that the user might want to know and act upon.
  ”Enter your coupon code to receive your discount.”

Taking this kind of softer approach leads to a more communicative system, that allows users to feel more in control while providing them with guidance they need.

Combining the two techniques - Proposals and Soft Validation – is a clean and powerful way to cleanly encapsulate domain validation.