One common thing I see people do is to develop validation routines for objects. These routines come in various ways, they may be in the object or external, they may return a boolean or throw an exception to indicate failure. One thing that I think constantly trips people up is when they think of object validity in a context independent way, such as an isValid method implies. […] I think it’s much more useful to think of validation as something that’s bound to a context , typically an action that you want to do. Such as asking if this order valid to be filled, or is this customer valid to check in to the hotel. So rather than have methods like isValid, have methods like isValidForCheckIn.
A uniqueness constraint can be reduced to a persistence exception, rather than being seen as an "invalid state". It's not an invalid state until the object is persisted. Uniqueness only makes much sense in the context of persistence. Realistically, you can put this kind of rule in your validation mechanism to help reduce the likelihood of this error, but in any real multiuser system, you can't be guaranteed of uniqueness until a successful unit of work completes the persistence action.
So you may want this in your validation mechanism, but you must enforce it in your persistence layer.