Validation in a DDD world

"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."

What about cases when you put your validation in your entity constructor? Do you consider that an anti-pattern?

I've been doing this to ensure my entities aren't created in invalid states and it's been working fine so far - but I'm interested to hear if there are some downsides to this. (obviously it doesn't cover all validation scenarios, but still... it is validation done on the entitiy)

Thanks for this info, Jimmy! what you're saying makes a lot of sense, and helps to answer some of the questions i posted, and validates some of the things i've been thinking and trying recently. i definitely need to go back and read up on the command query separation section.

Cool beans.  Your post has led my mind in some new directions regarding validation, I'll be sure to read the suggested material, hopefully that will help to further illuminate my understanding.

Thank you for submitting this cool story - Trackback from DotNetShoutout

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #287

After reading the numerous articles/comments etc from Derick, Sean etc. I figured I'd share the current approach I have decided to follow.

First, the methodology I currently use has grown from the concepts JP Boodhoo has presented in the past. Furthermore, I do not like attribute driven validation frameworks nor do I like IValidatable.IsValid methods in my entities.

Simply, I prefer just to have validator classes IValidator<T> with Validate(T entity). These validators can then be injected into my services, presenters etc. Simplifies testing and makes the design pluggable.

In my experience, coupling the validation into an entity can "paint yourself into a corner". Take for example an Event Management system. Say you have a Registration aggregate.  The Registration could be validated differently based upon its state. For example, consider the following progression of the registration in the enterprise: pending->processing->approved->imported into CRM. Each one of those "states" would likely require different validators and different validation logic. With IoC containers, its easy enough to load a validator based upon an entity state.

"In an attempt" to manage "reactionary validation", I follow an implementation which leverages "validation rules". Those rules objects ultimately include lambda expressions, descriptions, names etc. The validators would then just leverage those rules inside its Validate method.

Update: There’s a wealth of knowledge out there that I just haven’t been aware of until now. Thanks to

@Jimmy

Indeed, and I'm not creating my entities from my UI, so I don't run into this issue (nor am I using exceptions, preferring a Notification approach). I tend to have UI validation as close to the UI as possible, so I end up in a similar situation to what you're talking about with multiple validation points - still trying to get comfortable with this approach though.

I find it useful to have the validation on the constructor to ensure that re-hydrated entities and those created within the domain itself are always in a valid state. With the IValidateForLoading approach you were discussing, how does this work in terms of creation? Do you just ensure that you call the appropriate method during the constructor? Or is this some sort of post-loading hook for an ORM?

(also forgot to point out that for complex creation scenarios, a fluent Builder approach has worked well for us too - this gives you more flexibility over just having a constructor - and child entities, related entities, etc can be validated too)

Jimmy,

For your next post, I would love to see a quick-and-dirty C# example outlining the concepts above for a common, everyday situation, e.g. ChangePassword or some other well-known scenario.  Specifically what I'd like to see is how information relating to invalid inputs, etc. flows back to the UI.

Regarding the "Closure of Operations" you mentioned, from what I remember this is a way of saying “XYZ in XYZ out”.  This makes it sound as like you're passing a simple DTO as a parameter of the command object and then evaluating a Boolean on a returned DTO of the same type for success/failure as well to determine which values on the DTO are invalid and/or missing.

Jimmy Bogard presented a well written argument for always keeping validation out of entities in a domain

Jimmy Bogard presented a well written argument for always keeping validation out of entities in a domain

@Dennis Kozora,

"With IoC containers, its easy enough to load a validator based upon an entity state."

Are you implying that you are placing business/validation logic inside your IoC container?

Hey Jimmy,

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?

@bogardj,

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"?

I'm not sure I see why it's such a bad thing to have validation in the entity objects.  

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<T> 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.

Not sure I agree with this post. You describe the validation within the domain as if its an awful idea and the examples you give make it sound ridiculous and not consistent with DDD but I don't think thats in any way true:

>  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").

Who Knew Domain Validation Was So Hard?

@Jimmy

One question, when you talk about commands are you talking about command objects or command messages? I think its the former.

hi jimmy,

i read your post on validation at grabbagoft.blogspot.com/.../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

Where should validation go?

Just ignored this problem all the time. Seemed fine to add it where it was needed.

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

If you are enforcing command query separation so that your domain model only contains behaviors, why wouldn't you put the validation within each bahavior method? I dont see what is wrong with this. I think each method should be responsible for checking whether that operation can be performed and returning a summary of problems to the caller. Putting it anywhere else seems like your domain objects can be manipulated with no restrictions and possibly put in an invalid state. Does anyone see any downside to this approach?