Geeks With Blogs
Mike Nichols - SonOfNun Technology If I were the captain on a big steamboat...

One of the things that requires a realignment in thinking when moving away from RAD development tools as a means of solving business problems into a Domain Driven approach is where to put validation and how to provide meaningful messages back to the user when something goes wrong.

It seems to me that a good indicator of an anemic strategy for validating data is lots of work being done with validation controls and checks at the presentation (view) level. That doesn't mean that careful validation and thoughtful strategies at this layer are useless, but rather we shouldn't DEPEND on this layer to guard our datastore from bad data. Personally, I love using Peter Blum's Validation Controls for my web pages because he has taken great pains to create a rich set of controls that do one thing VERY well...validate at the client-side. Still, before I implemented a rich validation scheme across my layers in my app, I was spending TOO MUCH time with these controls to do work that belonged in the Domain Layer.

A neat approach to validating entities in the Domain layer can be found on JP Boodhoos site where he has a thorough explanation of a kind of reactive validation scheme. It's simple and easy to implement as well as flixible, should you want to apply different rules on the same entities.

After being careful in validating data and implementing strategies in the 'lower layers' I discovered that I had to do very little to guard my user's input from garbage data. All of a sudden, I didn't have to have a ton of validation controls checking conditional comparisons or making sure data was complete before posting because the thoughtfulness that was applied to the domain layer bubbled up to how I designed my User Interface strategy.

So for me, when I find myself having to accomodate complex rules in the User Interface, I need to take a step back and see if there is some insight in the Domain Layer that i haven't gotten yet...for example,

  • Is there YAGNI lurking in my design that might simplify things vertically across the layers?
  • Did I let my own business specs creep in, or are my requirements actually coming from the stakeholders?
  • Am I building my User Interface TOO SOON? Maybe I need to understand my domain better if I am adding and deleting controls like crazy.
  • Am I relying on textboxes with elaborate javascript do things that CODE should do in the layer beneath?
  • These are good questions to ask when i am sticking a million validation controls on my page.

    I kind of think of clientside validation like the guys with the bows and arrows on top of the wall around the city when the Orcs are marching in with their bad typing skills. They can take out quite a few of the bad guys, but really the heart of the protection is going to take place by the fellas in the Domain layer with their swords and magic wands. The women in my database are relying more on the guy with the battle axe than the guy with the slingshot.

    Posted on Tuesday, September 12, 2006 9:42 AM ASP.NET , OOP, Patterns, Architecture , Domain Driven Design (DDD) | Back to top

Comments on this post: Validation With Bows and Arrows or With Battle Axes and Swords?

# re: Validation With Bows and Arrows or With Battle Axes and Swords?
Requesting Gravatar...
I personally believe that simple (non-empty, comparison, or regex) validation is the only thing that really belongs in the UI.

Complex logic really belongs server side and the client-side script is an important usability construct that should NOT be overlooked. It's okay to duplicate tiny pieces of validation like those b/c they are easy to implement (or automate) and it makes your app more robust.

...and, you're right, Peter Blum's validators ROCK!
Left by Ben Scheirman on Sep 19, 2006 6:07 AM

Your comment:
 (will show your gravatar)

Copyright © Mike Nichols | Powered by: