O que é injeção de dependência e que problema ela realmente resolve?

Injeção de dependência significa que um componente recebe seus colaboradores de fora em vez de construí-los ele mesmo. O problema que resolve é acoplamento: se uma classe cria o próprio cliente de banco, você não consegue trocar, testar isolado nem controlar o tempo de vida dele. Passar as dependências pelo construtor as torna explícitas, faz a classe ser honesta sobre o que toca, e deixa você fornecer um fake nos testes ou uma implementação diferente por ambiente.

Significa só que a classe recebe o que precisa em vez de montar. Se o meu serviço de pedidos constrói o próprio cliente Postgres no construtor, ele está soldado ao Postgres e à connection string que estiver no ambiente, e todo teste dessa classe virou um teste de integração. Se ele recebe uma interface de repositório como parâmetro de construtor, eu passo a real em produção e uma em memória nos testes, e a classe não se importa. O benefício que eu passei a valorizar mais com o tempo é honestidade: a assinatura do construtor te diz exatamente o que essa coisa toca, então quando uma classe recebe sete dependências isso é um cheiro de design que você enxerga em vez de ter que ir procurar. Eu quero deixar claro que não acho que você precise de um container. Em serviços menores eu conecto tudo na mão num arquivo de composição, e esse arquivo vira o mapa do sistema. Frameworks ajudam quando a fiação fica tediosa, não antes.