Domain Driven Design has this notion of a Specification. The term is actually pretty self-explanatory, but here's what Eric Evans means:
... explicit predicate-like VALUE OBJECTS for specialized purposes. A SPECIFICATION is a predicate that determines if an object does or does not satisfy some criteria.
My understanding of a Specification is enforcement of your constraints and thus guarantee of a well-defined state of your domain objects. The most interesting idea is that the responsibility of validation lies within the domain layer. There are no service objects, containing validation logic, instead you add behavior to your domain model.
If you have a services layer, which provides various interfaces with a variety of technologies, you should make sure that your domain objects, which are passed in, are being validated before processing them. It's likely that there are consumers of your services, which can sometimes guarantee a well-defined and valid state of domain objects and sometimes not - depending on their characteristics.
Let's say you have a rich client, consuming your services. You probably want to perform validation before you call out to the server. In case of an expensive validation you potentially take some load of the server and avoid a roundtrip. Since you want to have the same service interfaces for different client technologies you either end up conducting validation on multiple levels - on the client and the server - or you discount the advantages of the rich client and only validate on server-side.
I tend to go with multiple validation and have a rich client validate before going on a roundtrip, but I'm not sure if this will work out as expected. There must be validation before having the server processing domain objects which were passed in. There is no way around that, only if you feel suicidal. One thing that you should avoid is duplication of validation logic. I think sticking to the DDD notion is crucial, because it helps maintaining and testing logic at a single spot in your code.