Anemic Domain Model in Typical Spring Projects (Part 1)

When I just started my career as a Java developer, I knew only a few basic design patterns. I tried to implement them everywhere, even when I shouldn't have, and I thought that more experienced people use them on a daily basis. With time, I have changed several different teams and companies, but I have never seen real usage of “real” patterns. Of course, I am not talking about Builder, Singleton, or Abstract Fabric, but rather about more complicated and less common ones like Bridge, Observer, etc. Familiar situation, isn’t it?

Basics

For a full understanding of the problem, we should begin with the basics. 

Anemic Domain Model in Typical Spring Projects (Part 2)

(Continued from Part 1)

Rich Domain Model Extreme could be an alternative, but in my opinion, you shouldn’t inject infrastructure classes to domain classes. Such code will quickly become unsupported and hell for testing, because every programmer has their own style of coding and in practice, this often violates conventions and good practices. Therefore, experience is tremendously important in this case. That is why we have to find some balance in anemic and rich models. In order to get a deeper knowledge of this topic, I would recommend reading this article.