Anemic Domain Model and Service facade

[klr8]

Martin Fowler makes a very good point in his blog entry http://martinfowler.com/bliki/AnemicDomainModel.html about Anemic Domain Models: i.e. you should try to put all your business logic on you domain model objects.

But what about business rules that are hard to check in the domain model? A typical example would be: "the userId of my User domain object should be globally unique". Since the User object is not aware of the database, nor of all other existing User objects, it can't really do this check.

So this leads us to the question: is it ok for such a check to be done by a service object? Or should you refactor your domain model so that there is an object that can perform the check (e.g. a UserManager domain object that keeps track of all existing users)?

Erwin

[Alarmnummer]

My experience so far:
don`t attach to much value to those remarks. If you want to do it good, you get more questions than answers. I haven`t found good solutions for a lot of domain-related problems.. everybody has (good) comments.. but nobody has solutions..

[Martin Kersten]

But what about business rules that are hard to check in the domain model? A typical example would be: "the userId of my User domain object should be globally unique". Since the User object is not aware of the database, nor of all other existing User objects, it can't really do this check.

In terms of a single user object the unique userId constraint is a constraint of the environment (only needed on creation time which is outside of the scope of the user type). So this is nothing to put into a user object.