Domain Logic

[The Anemic Domain Model] [n]ecessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).

http://en.wikipedia.org/wiki/Anemic_Domain_Model

but...

[Some are] just technical constraints, according to Dahan: “The business doesn’t care that username fields are 8 characters. Usernames have to be unique for technical reasons to be able to select customers to check details”. Rules that are not part of genuine domain logic do not have to be implemented in the domain model, suggested he, because they do not model the domain. They may be deployed to a separate tier.

http://agile.dzone.com/news/biggest-mistakes-teams-make

Udi again:

Validation of string lengths, data ranges, etc is not domain logic and is best handled elsewhere (and a topic for a different post). The same goes for uniqueness.

http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/