There's a very good reason why Spring is used so widely.
Complex enterprise apps are often complex because the use case and the environment is complex.
E.g.:
- integration testing and unit testing is required
- transparently pluggable backends for message queues so that locally you can use SQLite as your pub/sub storage but in production it's Google P/S
- standardized health check endpoints for all your apps
... The list is infinite. You can make a decision for each point or you can agree with the team that you're using whatever Spring provides.
In a team with 100 devs, simplifying and unifying decisions is extremely important. And Spring _works_. I don't like it either, but it works.
The alternative is: solving all the problem that Spring solves with different tooling. And no, you can't avoid dependency injection in a 700 kLOC medical application, because you need to test the hell out of it.
Complex enterprise apps are often complex because the use case and the environment is complex.
E.g.: - integration testing and unit testing is required - transparently pluggable backends for message queues so that locally you can use SQLite as your pub/sub storage but in production it's Google P/S - standardized health check endpoints for all your apps
... The list is infinite. You can make a decision for each point or you can agree with the team that you're using whatever Spring provides.
In a team with 100 devs, simplifying and unifying decisions is extremely important. And Spring _works_. I don't like it either, but it works.
The alternative is: solving all the problem that Spring solves with different tooling. And no, you can't avoid dependency injection in a 700 kLOC medical application, because you need to test the hell out of it.