¿Qué es la inyección de dependencias y qué problema resuelve en realidad?

La inyección de dependencias significa que un componente recibe sus colaboradores desde fuera en lugar de construirlos él mismo. El problema que resuelve es el acoplamiento: si una clase crea su propio cliente de base de datos, no puedes cambiarlo, ni probarla de forma aislada, ni controlar su ciclo de vida. Pasar las dependencias por el constructor las hace explícitas, hace que la clase sea honesta sobre qué toca, y te deja poner un doble en los tests o una implementación distinta por entorno.

Significa simplemente que a una clase se le entrega lo que necesita en vez de que lo construya. Si mi servicio de pedidos construye su propio cliente de Postgres en el constructor, está soldado a Postgres y a la cadena de conexión que haya en el entorno, y cada test de esa clase pasa a ser un test de integración. Si toma una interfaz de repositorio como parámetro del constructor, paso el real en producción y uno en memoria en los tests, y a la clase le da igual. El beneficio que he ido valorando más con el tiempo es la honestidad: la firma del constructor te dice exactamente qué toca esta cosa, así que cuando una clase toma siete dependencias eso es un olor de diseño que se ve en vez de uno que hay que ir a buscar. Quiero dejar claro que no creo que haga falta un contenedor. En servicios pequeños lo cableo todo a mano en un fichero de composición, y ese fichero se convierte en el mapa del sistema. Los frameworks ayudan cuando el cableado se vuelve tedioso, no antes.