At least now I’ll know what to say next time someone will ask me this question.

In that case, if Order completely manages the OrderLines, it might belong in Order. Or, in OrderLine, and Order calls Validate on each order line. Either way, I’d let the Inappropriate Intimacy smell guide you.

i read your post on validation at http://grabbagoft.blogspot.com/2007/10/entity-validation-with-visitors-and.html.

i tried to post there and saw this blog and thought this is your new blog.

anyway, in your example lets say Order has many OrderLines. for an Order to be valid for persistence, all the OrderLines also needs to be valid. now where does the validation of OrderLines belong?

thanks

> If we treat our entities as data holders, we might think to
> put all of our validation there, in the form of reactive
> validation, where the entity is allowed to be put into
> an “invalid” state.

Not sure thats true, if you view your entities as behavioral then you ask them to do X and they tell you whether they are happy with this (bearing in mind their current state).

> If all of your validation is on your entity, why are you even
> doing the Domain Model pattern in the first place?
> Validation directly on entities is more suited for CRUD-y
> applications, where patterns like Active Record are more
> appropriate.

It definitely wouldn’t/couldn’t all be in your entity, not sure anyone would argue that. I’ve had this discussion with Greg a few times and I see the point and I like the always valid idea but I don’t think its that or you’re doing CRUD and shouldn’t be worried about a domain model.

> Are we supposed to capture all of this in a single Validate
> method? I certainly hope not.

Don’t think anyone would recommend. Entities co-ordinate behavior, they should be kept light so in this case the validation method(s) would at most co-ordinate other objects. So if your Order does go through different states then each state class could have its own validaiton rules.

> If you have to put validation on an entity, make sure you
> capture the context of what the operation the validation is
> operating against, likely in the name of the method

Absolutely, but thats the key point…validation is entirely contextual. In some cases validation is an either/or thing, an aggregate is valid or it isn’t.

However once you get interesting behavior involved its “valid for X”, which is in my view where the always valid approach and the normal approach draw together.

> And that’s where I think we should move towards in terms
> of validation. Instead of answering the question, “is this
> object valid”, try and answer the question, “Can this
> operation be performed?”.

Absolutely, but thats true whatever approach you take. And one way to help with this is to move behavior into your domain model, including your entities (again though, they probably co-ordinate the behavior rather than containing the code). In that context it becomes “are you prepared to do X, no, OK I’ll report notification of reasons why” and then “do X, oh you’ve told me in no uncertain terms your not happy to participate in that behavior”.

> In my Command object, I’ll do further business rule
> validation, where I might need to coordinate between
> several different entities to determine if this operation can
> be performed successfully.
> And that’s where I think we should move towards in terms
> of validation. Instead of answering the question, “is this
> object valid”, try and answer the question, “Can this
> operation be performed?”.

Not sure I like that, that mindset totally turns your entities into data-holders. Absolutely I agree on focussing on behavior, and co-ordinating that behavior, but moving it all into commands…na.

> Because our command objects know answers to all of
> the “Who, what, why” questions, they are in the best
> position to perform contextual validation based on the
> operation the user is trying to execute

If its cross aggregate then I’d use a service (which I assume is similiar enough to be the same idea), if its within the boundaries of a single aggregate then I think the aggregate root itself has all it needs as long as the method you call is correct (“DoX”).

I’ve worked on a bunch of thick client apps. In these apps, the user can change data in numerous different places, as opposed to a web app where you’re going to call a controller method or post to a page, etc.

Even in a web app (let’s say I’m using an MVC framework), if I put my validation in my controller action methods, it’s possible that more than one controller could edit the same entity object and that I could need to put the same validation logic in more than one place. In some cases, I can see why the controller validation method makes sense.

I’ve always done the IsValid() on the entity that throws an exception when IsValid() determines that the entity is not valid. I’m open to other ways, but I haven’t seen anything else yet. I’ve done the IValidator thing that another commenter mentioned, although I don’t totally see what I gain from doing it that way (at least for 95% of validation situations).

If you have a better way than the way I’m doing it, I’d be interested in that post and specifically why you did it a certain way.

How do you get the OperationResult back to the application service? Return it from the domain method? That doesn’t seem likely as you’d be constraining your domain model. Is it similar to what Udi defines in his “domain events”?

OperationResult is just for us a result of an operation. It has a Success property and an ErrorMessages property, as well contextual information.

I’ve been trying to wrap my head around the validation concept.

For example, I’m working on a system right now that tracks build numbers on products. I have a business rule that states numbers can’t go backwards. For example, I have product A which is version 1. Bob goes and makes it version 3. Alice comes along and tries to make it version 2. In my mind, this is clearly a business rule that belongs in the entity representing the product. But I need to communicate with Alice that she tried to “move backwards”.

Right now, the product entity simply throws an exception. My application service knows how to handle that exception. But this feels like using an exception for flow control which is a huge smell to me.

I’ve seen mentioned in several places a “Result” object. Is this basically a local context object that collects data as the domain is executed?