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

I have an Aggregate called Person that has a method called AddAddress which accepts an IAddress invariant to (hopefully) be added to the Person.Addresses collection. Within the method body of AddAddress, I am invoking a Command object that goes down a list of Specifications and if all are passed, then the address is added to the collection. So far so good.

Now, i am calling this method from my Service layer and am expecting an IAddress object in return. If it fails, what is the best way of communicating that back to the client-caller (Service)? I don't like using exceptions for this kind of granularity and it seems like Aspect Oriented Programming might be screaming at me to apply its paradigm.

If I am applying a kind of 'lazy' validation on Domain entitiies (it doesn't know it is invalid until an object has been added to it to make it so), what is the best way or messaging back to my caller that the attempted action bombed and HERE'S WHY. I could return a Specification that wraps the return object and has the specs that were broken along the way in the Command pattern...but that seems stinky.

What has been your experience with this?

Posted on Tuesday, September 5, 2006 12:59 PM OOP, Patterns, Architecture , C# , Domain Driven Design (DDD) | Back to top

Comments on this post: Domain Validation Considerations

# re: Domain Validation Considerations
Requesting Gravatar...
The basic rule for raising exceptions is that if a method can't do what it says it's going to do (i.e. AddAddress) then you raise an exception. Check out Scott Hanselman's blog post for additions tips.
Left by David Totzke on Sep 05, 2006 5:25 PM

Your comment:
 (will show your gravatar)

Copyright © Mike Nichols | Powered by: