5

Nada pode depender diretamente de implementação concreta.

Parei aqui.

Não dá pra confiar no post de um autor que segue segamente clean architecture.

Usar abstração pra tudo?

Tenho um feature: LoginUserHandler, ela vai ser chamada por um endpoint de api, não vai ser reutilizada em nenhum outro ponto, porque sou obrigado a criar uma interface pra ele?

  • Não, a classe não vai mudar frequentemente
  • Sim, se mudar vou ter que refatorar o endpoint também
  • Não, não vai melhhorar a testabilidade, posso construir direto a classe concreta

E claro, sei DI vai ficar sobrecarregado, vai perder uma performance absurda (até 30%) apenas resolvendo dependency graph

Quem defende a criação de uma interface que terá uma única classe concreta e defente performance no mesmo post não deve ser levado a sério

Carregando publicação patrocinada...
1

Fala Pilati, tudo bem?

Obrigado pelo comentário e pela provocação. Você tocou num ponto excelente e, para ser honesto, eu concordo 100% com o seu exemplo prático.

Se você tem um LoginUserHandler que só roda em um endpoint, não é reaproveitado e não muda, criar uma interface para ele é o clássico exemplo de abstração prematura - algo que inclusive cito na seção de Regras de Código: Evite abstração prematura e Não crie genericidade sem necessidade real. É isso: Não crie burocracia desnecessária.

Não afirmei que trouxe todas as regras e princípios essenciais aqui ou que a arquitetura que embasei estes princípios é a melhor, apenas apresento um caminho viável para o desenvolvimento de sistemas grandes. Funciona. Porém, pode ser melhorado... tudo depende do contexto.

Leve em consideração que a filosofia base pode nortear as decisões:

  • Toda decisão deve equilibrar: velocidade, custo, manutenção, escalabilidade, clareza. Se estiver em dúvida, escolha a opção que balanceia melhor esses aspectos.
  • "Código bom é código previsível." Interfaces trazem previsibilidade ao que está acontecendo onde há volatilidade.

O ponto central da regra "Nada pode depender diretamente de implementação concreta" ganha real valor quando estamos falando das fronteiras externas do sistema: banco de dados, APIs de terceiros (gateways de pagamento, serviços de e-mail) ou regras de negócio centrais que mudam de direção conforme o produto evolui. Se o seu código acopla direto na biblioteca específica de um terceiro, quando eles mudarem a API, seu core quebra. É ali que o contrato (interface) te salva.

Concordo com o ponto do grafo de DI e performance, embora tenha variações, aqui equilíbrio é chave.

Agradeço demais por trazer seu contraponto, porque ele deixa claro algo fundamental: nenhum manifesto ou arquitetura deve ser seguido de forma cega. O contexto e o pragmatismo sempre devem mandar na tomada de decisão. Tenho isso como princípios basilares (trato isso em Filosofia Base).

Tenho certeza de que você tem alguma linha de corte para decidir quando vale a pena isolar em uma interface ou ir direto na classe concreta.

Obrigado mais uma vez, abraço!