SOLID costuma ser ensinado com exemplos de Java corporativo, distantes do dia a dia de quem programa em Laravel. Na prática, uso os cinco princípios o tempo todo — só que de forma menos cerimoniosa do que os livros sugerem.
Os dois que mais uso
Responsabilidade Única e Inversão de Dependência são os que aparecem em quase todo Controller e Service que escrevo: um Controller não deveria conter regra de negócio, e uma classe de domínio não deveria instanciar diretamente um serviço externo — ela deveria receber uma interface, injetada pelo container do Laravel. Isso sozinho já resolve boa parte dos problemas de acoplamento que vejo em projetos legados.
Um exemplo prático: em vez de uma classe de envio de certificado chamar diretamente uma biblioteca de PDF, ela recebe uma interface GeradorDeDocumento. Hoje essa interface é implementada com uma biblioteca; amanhã pode ser outra, ou pode virar uma chamada a um serviço externo — e a classe que usa a interface não muda uma linha. Essa troca só é possível porque a dependência aponta para uma abstração, não para uma implementação concreta.
Os outros três, com menos cerimônia
Aberto/Fechado, Substituição de Liskov e Segregação de Interface aparecem menos explicitamente no meu código, mas orientam decisões: evito classes que precisam ser modificadas toda vez que uma nova regra aparece (prefiro estender), evito herança que quebra comportamento esperado, e prefiro várias interfaces pequenas a uma grande que força implementações desnecessárias.
Onde SOLID vira exagero
Também já vi o oposto dar errado: interfaces para tudo, uma classe para cada princípio, código fragmentado ao ponto de ninguém conseguir seguir o fluxo. SOLID é um conjunto de princípios para guiar decisão, não uma checklist obrigatória em cada linha. Uso o bom senso: aplico onde reduz acoplamento real, ignoro onde só aumentaria a indireção sem ganho — o mesmo raciocínio que uso para decidir entre MVC puro e uma arquitetura em camadas.
