1
resposta

[Dúvida] Beans Elegantes vs Clean Arch

Eu vi anteriormente, aqui nesse fórum, um aluno perguntando se havia como configurar um bean de forma menos verbosa e mais elegante. A resposta do Renan Lima foi muito intuitiva. Porém me levanta outra dúvida: Os usecases estão internos em relação à camada do framework. Ao anotá-los com @Service e @Autowired, você faz a camada interna acessar a camada externa, quebrando a proposta do Clean Code. Isso resultaria, em caso de troca de framework, em problemas para a migração do novo framework, né?

Então essa prática pode não ser a mais recomendada, certo?

1 resposta

Olá! Tudo bem?

Você levantou uma questão muito interessante sobre a relação entre a configuração de beans e a aderência aos princípios da Clean Architecture.

De fato, um dos pilares da Clean Architecture é manter as camadas internas independentes das camadas externas, o que inclui não depender de frameworks específicos.

Quando você anota seus use cases com @Service e utiliza @Autowired, você está, de certa forma, acoplando sua lógica de negócio ao framework, que no caso parece ser o Spring. Isso pode, sim, criar dificuldades se você precisar migrar para outro framework no futuro, pois essas anotações são específicas do Spring.

Uma prática mais alinhada com a Clean Architecture seria usar injeção de dependência manual ou por interfaces, mantendo assim a camada de negócio independente do framework. Por exemplo, você pode definir interfaces para seus use cases e usar uma classe de configuração para instanciar e injetar essas dependências. Dessa forma, a lógica de negócio não precisa conhecer o framework que está sendo usado.

Aqui está um exemplo simplificado de como isso poderia ser feito:

public interface UseCase {
    void execute();
}

public class MyUseCase implements UseCase {
    @Override
    public void execute() {
        // lógica do caso de uso
    }
}

// Configuração manual
public class UseCaseConfig {
    public UseCase myUseCase() {
        return new MyUseCase();
    }
}

Com essa abordagem, você mantém a lógica de negócio desacoplada do framework, facilitando futuras migrações ou mudanças.

Espero ter ajudado e bons estudos!

Caso este post tenha lhe ajudado, por favor, marcar como solucionado ✓.