I'm new to dependency injection and started to study Google Guice. I get the IOC concepts and all that, and how to bind and inject dependencies. But what I'm trying to wrap my mind around is whether it is meant to be a universal design
pattern for all applications (big and small), or only in testing-intensive environments.
I work on a small team of three people, and we build commercial Swing applications for about twelve internal users. We deal with a lot of complexity and rapid business changes, doing release cycles every two weeks. We have established our best practices for our needs with a huge emphasis on immutable class design.
I currently can only see about 10% of our classes being leveraged through dependency injection, mostly database-related classes and parameters. But the other 90% I don't really see the benefit of creating interfaces to things we really only need one implementation of. It's just more boilerplate. I can see that would be helpful with
testing but there's just a lot of class dependencies that I don't really see the value in decoupling. Maybe I'm just not seeing the big picture. Is Dependency Injection really supposed to the drive the design of every single class that has a dependency on another class, even if it the dependency is trivial or seems inconceivable another implementation of that class would be used? Or is its usage meant to be used judiciously and primarily for testing-intensive designs? What am I missing that would make me drink the DI Kool-Aid?