Validation should be performed as soon as possible.
Validation in any context, weither Domain model or any other way of writing software, should serve the purpose of WHAT you want to validate and at which level you are at the moment.
Based on your question, I guess the answer would be to split the validation.
Property validation checks if the value for that property is correct e.g. when a range between 1-10 is expeced.
Object validation guarantees that all properties on the object are valid in conjunction with each other. e.g. BeginDate is before EndDate. Suppose you read a value from the data store and both BeginDate and EndDate are initialized to DateTime.Min by default. When setting the BeginDate, there is no reason to enforce the "must be before EndDate" rule, since this does not apply YET. This rule should be checked AFTER all properties have been set. This can be called at the aggregate root level
Validation should also be preformed on the aggregate (or aggregate root) entity. An Order object may contain valid data and so do it's OrderLines. But then a business rule states that no order may be over $1,000. How would you enforce this rule in in some cases this IS allowed. you can't just add a "do not validate amount" property since this would lead to abuse (sooner or later, maybe even you, just to get this "nasty request" out of the way).
next there is validation at the presentation layer. Are you realy going to send the object over the network, knowing it will fail? Or will you spare the user this burdon and inform him as soon as he enters an invalid value. e.g. most of the times your DEV environment will be slower than production. Would you like to wait for 30sec before you're informed of "you forgot this field AGAIN during yet ANOTHER test run", especially when there is a production bug to be fixed with your boss breathing down your neck?
Validation at the persistence level is supposed to be as close to property value validation as possible. This will help prevent exceptions with reading "null" or "invalid value" errors when using mappers of any kind or plain old data readers. Using stored procedures does solve this problem, but requires to write the same valiation logic AGAIN and execute it AGAIN. And stored procedures are the DB admin domain, so don't try to do HIS job as well (or worse bother him with this "nitty picking he's not getting payed for".
so to tell it with some famous words "it depends", but atleast now you know WHY it depends.
I wish I could place all this in a single place, but unfortunately, this can't be done. Doing this would place a dependency on a "God object" containing ALL validation for ALL layers. You don't want to go down that dark path.
For this reason I only throw validation exceptions a property level. All other levels I use ValidationResult with an IsValid method to gather all "broken rules" and pass them to the user in a single AggregateException.
When propagating up the call stack, I then gather these again in AggregateExceptions until I reach the presentation layer. The service layer can throw this exception straight to the client in case of WCF as a FaultException.
This allows me to take the exception and either split it up to show individual errors at each input control or flatten it and show it in a single list. The choice is yours.
this is why I also mentioned the presentation validation, to short circuit these as much as possible.
In case you're wondering why I also have the validation at the aggregation level (or service level if you like), it's because I don't have a crystal ball telling me who will be using my services in the future. You'll have enough trouble finding your own mistakes to prevent others from making there mistakes yours :) by inputting invalid data.e.g. you administer application A, but application B feeds some data using your service. Guess who they ask first when there's a bug? The administrator of application B will happily inform the user "there is no error at my end, I just feed in the data".