So do I . The framework I built at my prior job continues to be used to this day and processes 10’s of thousands transactions daily. Sometimes hourly (depending on the work they are doing). All of the components for it though could be rearranged to run an entirely different application and not just used for Insurance related operations.
Does it rely a lot on DI, yep! Why? Because it was test driven development and DI helped me solve how to test every aspect of my code thoroughly and in a practical way. Need to run your tests on a build server and mock the database so your tests can components can actually achieve what they need to do? Sure no problem, let me mock my database object and send that into the appropriate components. Need to prove that a component will fail in its responsible way if the database is down or has bad data? Sure, let’s mock the bad database connection and pass it in.
DI has been a huge benefit to me and the way that I code as I can write better tests. Better tests means I can churn out changes quicker, as I simply write a new test for the upcoming change, write the code, and then verify all tests still pass. If they do, I didn’t break anything! QA runs through their regression and integration tests (either in an automated fashion or manually) and things continue to move forward with ease.
Since going this route, the number of bugs produced from my changes have been zero. We’ve found issues with requirements or maybe a requirement was written incorrectly, but from what the requirements had, their test cases/scenarios, and the final result of development, zero bugs.
I unfortunately can’t say the same for some of the legacy systems that our devs do not write tests for, are riddled with tightly coupled dependencies, and although they “function”, the amount of time spent on fixing bugs, adding/updating functionality there is cost heavy and typically results in a new bug or two or dozen that most of the time gets caught in QA, but have edge cases that make it to Production as well.
So although I understand your framework doesn’t need it, mine and the confidence I have in it does and has saved the company a lot of money by letting them shift their focus from 20-25% of your time spent on bugs, to using that for new features.
That may be my experience and your experience may be entirely different, but if I were to start a project again from the ground up, I’d still follow a Test Driven Development path and ensure that my components can be fully tested and that would mean the usage of DI as a must.