One discussion I keep hearing come up again and again in the blogosphere, as well as in the pub, is that of the anemic domain model as an anti-pattern.
Whilst I can see the benefits of having a “full-fat” domain model, it seems to go against the Single Responsibility Principle (SRP). This is wonderfully illustrated by Robert Martin on the Hanselminutes podcast, about 3 minutes in. In this podcast Martin argues against having an object having multiple reason to change.
In this example, the employee class knows too much about it’s construction and persistence. This can be easily addressed using standard Domain Driven Design (DDD) Factory and Repository patterns:
However, we’re still left with the employee object having multiple responsibilities, and multiple reasons to change. Some argue that this is a good thing, however I think that particular example is more an illustration of the Liskov Substitution Principle.
Following Robert Martin’s example to its logical conclusion, we end up with an service-oriented architecture (SoA) approach, and an Anemic Domain Model.
So which approach would I use? A rich domain model or an anemic one, with an SoA and SRP? In my opinion it is easier to write a loosely coupled, testable, anemic domain with an SoA, than it is to write a full interactive domain. By using the SoA approach, you can essentially defer the question, "when should I split this functionality into another class?" - it is answered for you by the SRP.
With a greater level of skill required to write a good rich domain model, I tend to go for the anemic option when possible - it is easier to point to the SRP than it is to count on good OO design acumen. Of course, this depends on the project your working on and the people your working with.