Vale a pena ser tão puro? | Arquitetura Java: descomplicando a Clean Architecture

É proposto uma separação e isolamento total do domínio com frameworks. Isso é muito bom. Mas nada vem sem um custo.

A criação de configs para definição de todos os beans da aplicação é muito trabalhosa. Em projetos maiores começa a ficar exagerado.

Usar as anotações do framework Spring @Component e @Service no Domínio não seria uma violação aceitável?

Por um lado, esse framework é difícil ser trocado no longo ciclo da aplicação.

Por outro, a violação necessária é somente anotações, que não têm efeito sobre o código Java. Removê-las futuramente, se preciso for, é uma ação que pode ser feita por recursos na IDE, sem esforços adicionais ou implicações nas regras do Domínio.

Oii, Reinaldo.

Você tocou num ponto que muita gente se pergunta ao aplicar Clean Architecture: manter o domínio totalmente isolado do framework vale mesmo o esforço?

A resposta tá muito ligada aos objetivos e maturidade do projeto. Quando deixamos de usar as anotações como @Service e @Component dentro do domínio, ganhamos um código mais testável, mais fácil de migrar no futuro e com menos dependências externas. Isso é ótimo para projetos de longo prazo que buscam flexibilidade e manutenção fácil.

Mas, como você apontou, isso tem um custo. Em projetos maiores, a quantidade de configurações manuais cresce e pode parecer repetitivo ou até exagerado. Por isso, algumas equipes decidem aceitar pequenas violações — como o uso de anotações — para ganhar produtividade e simplicidade no curto prazo. É uma escolha consciente.

O importante aqui é que essa escolha seja feita com clareza. Mesmo que anotações não alterem diretamente a lógica da classe, elas ainda representam acoplamento. Se o time estiver ciente disso e confortável com o trade-off, tudo bem. Mas vale lembrar: quanto mais desacoplado o domínio, mais independente e reutilizável ele se torna.

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!