Sergiy Yevtushenko’s Post

Dependency Injection changed how we build software. But somewhere along the way, it acquired a second job it was never designed for. DI was meant to assemble applications from components. Wire a controller to a service, a service to a repository. Internal, deterministic, zero configuration. But most frameworks also use DI for resource provisioning -- database connections, HTTP clients, message brokers, caches. External resources that behave completely differently from internal components. The result? Your application bundles infrastructure it shouldn't own: - 60% of your pom.xml is infrastructure dependencies - Every environment needs different resource configs - Security patches in drivers require rebuilding every service - Credentials live inside applications instead of the runtime - Half your test setup mocks infrastructure that isn't your concern The fix isn't abandoning DI. It's recognizing these are two different problems that need two different solutions. Assembly: if it's your code, wire it automatically at compile time. Provisioning: if it's infrastructure, declare what you need and let the runtime provide it. The boundary is clear. We just stopped seeing it. Fifth article in the "We Should Write Java Code Differently" series: https://lnkd.in/dy-hiHDg #java #softwarearchitecture #backend #dependencyinjection

To view or add a comment, sign in

Explore content categories