Where do you put Validation in projects with Domain Driven Design?

Where should I place the Validation logic of the Domain objects in my solution? Should I put them in the Domain classes, Business layer or else?

I would also like to make use of Validation Application Block and Policy Injection开发者_如何学Go Application Block from Microsoft Enterprise Library for this.

What validation strategy should I be using to fit all these together nicely?

Thanks all in advance!

It depends. First - You need to understand what You are validating.

You might validate:

1. that value You retrieve from Http post can be parsed as date time,
2. that Customer.Name is not larger than 100 symbols,
3. that Customer has enough money to purchase stuff.

As You can see - these validations are different in nature, so they should be separated. Importance of them varies too (see "All rules aren’t created equal" paragraph).

Thing You might want to consider is not allowing domain object to be in invalid state.

That will greatly reduce complexity because at current time frame, You know that object is valid and You need to validate only current task related things in order to advance.

Also, You should consider avoiding usage of tools in Your domain model because it should be infrastructure free as much as possible.

Another thing - embrace usage of value objects. Those are great for validation encapsulation.

You can do either, depending on your needs.

Putting it in domain classes makes sure the validation is always done, but can make the classes bloated. It also can go against the single responsibility principle depending on how you interpret that (it adds the responsibility to validate). Putting it in domain classes also restricts you to one kind of validation. Also, unless you use inheritance, the same rule might have to be implemented multiple times in related classes (DRY). Validation is spread out through your domain if you do it this way.

External validation (you can get a validation object through DI, factories, business layer, or context) makes sure you can swap out the validation rules depending on context (e.g. for a long running process you want to save in a partially finished state you could have one validation object just to be able to save, and another to check whether the domain class is really valid and ready to be used). Your domain classes will be simpler (less responsibilities, though you'd have to do minimal checks, like null checks, to prevent run time errors), and you could reuse rule sets for related classes as well. Validation is centred in a small area of your domain model in this way. B.t.w. you can inject the external validation into the domain class itself making sure the classes do validate themselves, just don't know what they are validating.

Can't comment on the validation application block though.As always you have to weigh the pros versus the cons, there is never one valid solution.

First off, I agree with @i8abug.

But I did want to go a bit further to talk architecture. Every one of those design architectures, like domain driven, should be taken as nothing more than a suggestion and viewed with scrutiny.

At every step you should ask yourself what the benefit and drawbacks of the point in question is with regards to your application.

A lot of these involve adding a tremendous amount of code and seriously complicating projects with very little benefit.

The validation point is a prime example. As Stefan said, the principle of single responsibility basically says you need to create a whole set of other classes whose purpose is to only validate the state of the original objects. Obviously this adds a LOT of code to the app. Maybe it's generated for you, maybe you have to hand write it. Regardless, more code generally equates to being less robust and certainly equates to being harder to understand.

The benefit of separating all of that is that you can swap out validation rules. Ok, fine. The drawback is that you now have 2 files to look at and create for each class definition. ie: more work. Does your app need to swap out validation rules? Probably not. I'd even wager to say very very few do.

Quite frankly, if you go down this path then you may as well define everything as a struct and let all of those "helper" classes creep back to take care of validation, persistence, setting properties, etc as being a full blown class buys you almost nothing.

All of that said, I tend towards self contained classes. In other words they know how their properties relate to each other and know what are acceptable values. They can also perform operations on themselves and their children. In other words, they know what they are. This tends to lead to simplified coding and implementation. It also leads to knowing exactly where to go for a modification or change. The only separation I really do here is to implement Inversion of Control for persistence; which allows me to swap out data providers at runtime; which has been a requirement on several applications I've done.

Point is, think through what you are doing and decide if it's really the best way to go in your particular situation. All of these programming "rules" are just suggestions after all.

I generally put it in the domain objects. This is because the domain objects are the things that I am concerned about validating so if a rule for a specific object changes, I know where to update it rather than having to search through a bunch of unrelated entity rules in some specific validation class/file.

I realize this may not be considered POCO but every project has specific exceptions and this one often makes sense to me. Likewise, in some projects it makes sense to have your domain entities referenced from the views and, therefore, implement IPropertyChanged rather than constantly copying values from entities to a whole other set of view specific objects.

The old way I did validation was I had an IValidator interface like below which each entity implemented.

public interface IValidator
{
   IList<RuleViolation> GetViolations();
}

Now I do this using NHibernate Validation (don't need to use nhibernate ORM to take advantage of the validation library. It is done simply through attributes.

//I can't remember the exact syntax but it is very similar to this
public class MyEntity
{

[NHibernateValidation(Length(min=1, max=10)]
public String Name {get;set;}

}

//... and then later ...
NHibernateValidator.Validate(myEntity);

Edit: I removed my comment about not being a huge fan of enterprise library in general in the past since Chris informed me that it is now very similar to NHibernate Validation