<p>If you have a domain object, and you want to do something useful and central to that domain object's responsibility like ensure it is valid, you sometimes need to access the state of related objects in order to perform this validation. </p>

<p>How to avoid the domain object needing to call out to a Repository or Data Access Layer? You can't always walk the collection relationships, even with lazy loading, because of performance, and you often want to execute queries in the domain object. You can dependency inject repository implementation into the domain, but not really pure and complicates testing.</p>

<p>I've always relaxed things and allowed access out from domain to a repository using DI. I have seen no clear examples of how to have a 'pure' domain layer in a complex application which is not also anemic and has a service/application layer doing all the grunt and messing with what should be innards of the domain objects.</p>

If the object is a value object, it
should be immutable and validated
during construction.
If the object
is a root aggregate, and that its
own state is sufficient to tell you
if it is valid or not, you could add
a validation method on it, which
cascades through the aggregation.
Lastly, and I think it is your main
concern, if you need to access
several related objects (that are
not in the same aggregate) to ensure
one of them is valid, you
definitively needs to deport this
logic in a specific validation service.
I really think that injecting services and repositories into entities are not the best choice. Creating dedicated services seems more appropriate, and I don't see why it will leads you to have anemic domain objects.
In short, if you can validate you object state without relying on services or repositories, let the object takes care of it, at the aggregate root level. When you need to query services or repositories, or when you need other entities, then strongly consider moving this logic outside the object.