From Anemic to Rich Domain Model

I’ve been researching this subject lately since I’ve had many good conversations about the two approaches with my fellow co-workers. The Fowler’s term, Anemic Domain Model, was new to me even though I’ve used the both Rich and Anemic Domain Models in the past without giving much attention to the differences between these two approaches.

What is the difference between the Rich and Anemic Domain Models? I think that Martin Fowler describes this quite well in his blog post, AnemicDomainModel in 2003. Frans Bouma have also made a great posts about the different approaches. And in this post he describes quite well the differences between Entity Approach (Anemic Domain Model) and Domain Approach (Rich Domain Model). Here is my version of describing the difference between these two with simple UML diagram:

Anemic and Rich Domain Models in UML

Basic idea in Rich Domain Model is that the behavior is included in the domain object compared to Anemic Domain Model where behavior is implemented in separate classes. This will reduce the lines-of-code in the application layer and it also makes the application code more maintainable since the use of domain objects is more logical.

Fowler wonders in his post why this anti-pattern, Anemic Domain Model, is still so common nowadays and one reason that comes to mind is that the existing applications, especially enterprise level applications, have used this approach as de facto through decades. This might also be the reason for even the Wikipedia’s article to mention that some argue that this wouldn’t be anti-pattern at all. It feels like this subject divides developers to two camps in the same manner like different development platforms or operating systems.

Also the fact that this anti-pattern is used widely in the literature doesn’t help to adapt to the Rich Domain Model approach. I found a good example of this as I read the excellent book Agile Java Development with Spring, Hibernate and Eclipse written by Anil Hemrajani. Hemrajani writes about the POJOs but still uses the Entity Approach throughout the book.

Rich Domain Model ain’t a silver bullet but first few encounters have been very positive and looking forward on applying it more and more in the future projects.Подаръци