I am new in a team working on a grown and complex Spring MVC application. The application context is widely wired using @Autowire annotated constructors. This seems to be the main reason for the issue I see with the application: there is no global structure of the application. If someone implementing a bean A needs a feature of another bean B, he/she adds this other bean to the constructor of A, regardless of the package of B or the categroy of B. If any bean A (let it be a simple helper) requires session data, HttpSession is injected (a session proxy of course). Instead of passing domain objects to helper objects via method arguments, the helper gets access to a service to fetch domain data on its own. Over time this has led to a huge dependency network. I even saw comparator implementations relying on Spring services. One cannot spot any layers or tiers or modules or hierarchy in the application like (controllers/services/dataaccess).
It is my gut feeling that this is not a good architecture but gut feelings is not sufficient to convince my team that there is an issue with this application. It could also turn out that everything is fine and my gut should shut up ;-) I tried to search the web for possible Spring application anti-patterns but could not find supporting facts. So my questions:
- Is this issue known as some anti-pattern for Spring applications which expresses my concerns? As I said, I suspect the convenience of @Autowire as the main reason. It is too easy to make one bean depend on another.
- Do you know a book / article which focuses on best practices for Spring application architecture? Most stuff on Spring focuses on technical details, not so much on how to design sound architecture.
- Which problems will we get when continuing like described?