Anemic Domain Model

Martin Fowler notes:

“This is one of those anti-patterns that's been around for quite a long time, yet seems to be having a particular spurt at the moment. I was chatting with Eric Evans on this, and we've both noticed they seem to be getting more popular. As great boosters of a proper Domain Model, this is not a good thing.

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is very little behavior on these objects. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data....

...I don't know why this anti-pattern is so common. I suspect it's due to many people who haven't really worked with a proper domain model, particularly if they come from a data background. Some technologies encourage it; such as J2EE's Entity Beans which is one of the reasons I prefer POJO domain models.” [1]

IMO, the reason for this is pretty simple. This is no different than what we have consistantly seen with web app development. As soon as a technology starts to reach a critical mass, all the morts jump in and the average quality of design work begins to decrease (it doesn't help that VS.NET now makes creating these types of apps easy enough for the brain dead). When web apps started getting popular, we had to constantly tell people “Don't put business logic in your UI layer!” (and indeed, we still have to do this every once and a while). With SOAs, the new UI layer is the service layer. I assume more and more of the same design problems will begin to crop up in SOAs as they become more and more popular.

[1] Anemic Domain Model. http://martinfowler.com/bliki/AnemicDomainModel.html