I recently read a post on "[The Anemic Domain Model Pattern](http://codebetter.com/blogs/gregyoung/archive/2009/07/15/the-anemic-domain-model-pattern.aspx)" which caught my attention. As I read through this I found that the Anemic Domain Model description applied to many of the projects that I have worked on and built. I never thought of this as a bad design decision as it felt very natural. I thought that in the case where the [domain model](http://martinfowler.com/bliki/AnemicDomainModel.html) was light weight and not very complex the Anemic Domain Model moniker fit quite well. Why add complexity to the domain model where it doesn't need to be just so the title of "Anemic Domain Model" doesn't aptly describe your code?

**Question:** At what point does stuffing more of your code complexities into your service/application layer become in-correct in favor of exposing the complexity off of your entity objects instead? I am all for having a "Total" property on an Entity where it internally can figure out the value for the Total. I am not for making the Entity communicate directly with various other widgetry to determine the outcome of one of it's properties. So is the concept of an Anemic Domain Model an anti-pattern or a good separation of concerns? Is the title Anemic Domain Model always a bad thing?

Just curious what other people's thoughts were on this design (anti)pattern.