Anemic Domain Model's vs. Domain Model in a simple domain driven design

Question

I recently read a post on "The Anemic Domain Model Pattern" 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 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.

Answer 1

The key question is to ask why is the domain model anemic?

• Near-total absence of business logic, as in an application which is primarily an assemblage of CRUD screens?
• Service-oriented architecture in which the 'domain objects' are in fact simple structures data transfer objects?
• Political or pragmatic considerations such as code ownership or forward/backward compatibility that excessively impede refactoring?
• Applying procedural/relational design in an otherwise object-oriented language?

In any case, if I were to pick a simple rule of thumb for the boundary between domain model logic and service logic, it would be that interacting with related objects is fine within the domain, while accessing the "outside world" (user interface, web services, etc) probably doesn't belong in the domain model.