Pular para o conteúdo
Arquitetura

Clean Architecture na Prática: Transição de Camadas para uma Base

Aprenda, na prática, a migrar de arquitetura em camadas tradicional para Clean Architecture em Java, blindando seu domínio, desacoplando frameworks e tornando código fácil de evoluir.

Por que isso é importante

Resposta direta: em “Clean Architecture na Prática: Transição de Camadas para”, meça no seu contexto — hype e ranking não substituem eval e aceite.

Pasta não define arquitetura

O jeito como você nomeia pastas diz pouco sobre a arquitetura do projeto. O que realmente importa é a separação entre regra de negócio (domínio) e detalhes de implementação. Não é o layout do diretório que conta, mas sim onde mora a inteligência do sistema – e como ela se conecta ao exterior.

Atenção

Trocar nomes e mover arquivos não muda se seu domínio está exposto a bibliotecas ou frameworks – só o design da dependência importa.

Arquitetura Limpa: o Círculo Central Tem Blindagem Total

Em Clean Architecture, a camada mais importante é o domínio (core): entidades, regras, casos de uso e contratos com o mundo externo. Tudo ali dentro precisa funcionar sem depender de framework, banco de dados ou biblioteca externa.

Atenção

Qualquer annotation, importação de framework ou dependência técnica dentro da camada de domínio quebra a arquitetura limpa. É a regra número um.

Framework e Infraestrutura: Só na Periferia

Tudo que é detalhe técnico – banco, JPA, REST, validação, anotações – vive nas estruturas externas (infra). Só a infra pode depender do core, e apenas via contratos (gateways ou interfaces). O core não deve nem saber que essas coisas existem.

Conceito-chave: Fluxo de Dependência é do Exterior para o Centro

Seu core expõe contratos (interfaces), mas nunca chama infraestrutura diretamente. Externos acessam internos, jamais o contrário. Controllers chamam casos de uso, casos de uso usam gateways e entidades, gateways são implementados na infraestrutura. É uma via de mão única.

Anatomia: Como Organizar Pastas para Clean Architecture

Não precisa de milhares de nomes complexos. Com dois grandes pacotes você já separa tudo: core (domínio) e infra (infraestrutura). Dentro do core, use entities, enums, gateways, usecases . Na infra, coloque details, exceptions, mappers, persistence, presentation, gateways .

Ferramental: Stack Inicial Java para Arquitetura Limpa

Não precisa inventar a roda: Spring Web, Lombok, Postgres Driver, Flyway, Spring Data e Validation. Use o que for tecnicamente necessário na infra. No core, nada disso entra.

Primeiro Passo: Blinde o Domínio

Comece sempre criando o core: entidades, enums, gateways (contratos) e casos de uso. Jamais traga anotações, frameworks ou imports estranhos. Entidades podem ser records, desde que permaneçam puras.

Contratos: Gateways São a Ponte Entre Domínio e Mundo

Gateways são interfaces que definem operações do negócio: criar, buscar, cancelar. Vivem no core e só recebem ou retornam objetos do próprio core, sem tipos de frameworks. As implementações ficam na infra.

Use Cases: Um Caso de Uso para Cada Operação do Negócio

Para cada ação relevante – criar, atualizar, cancelar, concluir, buscar – crie um use case. No core, eles recebem e retornam apenas entidades ou valores. Testes unitários ficam simples, e você evolui o sistema sem medo de quebrar tudo.

Como Liga Tudo: Controllers e Adaptadores Só na Periferia

Controllers, endpoints, jobs e outros tratadores externos ficam fora do domínio. Eles apenas instanciam ou executam casos de uso via gateways, nunca acessando entidades de frameworks diretamente.

Erro comum

Acessar repositório, JPA ou frameworks direto do core elimina todo benefício da arquitetura limpa. É meio caminho andado para o acoplamento.

Infraestrutura: Faça Sujo, Mas Só Lá Fora

Packages da infra podem (e devem) conter detalhes técnicos: JPA, mappers, exceptions, beans, controllers, repositórios, tudo que é específico da stack. Só mantenha isso longe do core.

Migração de Camadas para Arquitetura Limpa: Panorama Visual

Na arquitetura em camadas tradicional, app chama controller, que chama service, que chama repository, que chama banco. Em Clean Architecture, controllers e detalhes orbitam o core, chamando use cases e gateways. Quando você troca banco, framework ou técnica, só mexe na periferia. O core permanece intocado.

Passo a passo real: do sistema em camadas para domínio limpo

Renomeie e estruture pastas: core (entities, enums, gateways, usecase), infra (details, exceptions, mappers, persistence, presentation, gateways). Comece migrando entidades (como record sem annotations), status (enum), depois gateways, e só então use cases. Deixe detalhes técnicos só pra infra. Instancie e injete dependências via contratos — e observe: ficou mais fácil testar, manter e evoluir.

Antes de implementar: checklist para não acoplar nada

Garanta: nenhuma annotation, import de tecnologia ou biblioteca externa no core. Contratos sempre no core e implementações só na infra. Foco no domínio puro, usando apenas tipos da linguagem base. Facilite sua vida: documentação visual (como no canal Dev Doido) ajuda a fixar. E sempre teste o core desplugado do resto!

Saber mais: aprenda arquitetura limpa vivendo código real

Compreensão verdadeira de architecture não vem só de diagramas ou tutoriais. Acompanhe vídeos, experimente refatorar projetos de verdade, e mantenha sempre o domínio protegido. Pratique, corrija e evolua até se tornar automático.

Atenção

Faça parte da comunidade Dev Doido no Youtube para visualizar migrações ao vivo, aprender com comentários e acelerar sua curva de aprendizado com projetos prontos.

Resumo prático: O que não esquecer

Arquitetura limpa é sobre separar essência de detalhe. O domínio não depende de nada externo, frameworks só orbitam o core via contratos, e a vida do desenvolvedor fica mais simples quando nada está acoplado ao banco, à API ou a qualquer stack! O segredo? Pratique, questione e evolua.

Perguntas frequentes

O que “Pasta não define arquitetura” explica de concreto?

O jeito como você nomeia pastas diz pouco sobre a arquitetura do projeto. O que realmente importa é a separação entre regra de negócio (domínio) e detalhes de implementação.

Qual takeaway prático de “Arquitetura Limpa: o Círculo Central Tem Blindagem Total”?

Em Clean Architecture, a camada mais importante é o domínio (core): entidades, regras, casos de uso e contratos com o mundo externo. Tudo ali dentro precisa funcionar sem depender de framework, banco de dados ou biblioteca externa.

O que o texto diz sobre Framework e Infraestrutura: Só na Periferia?

Tudo que é detalhe técnico – banco, JPA, REST, validação, anotações – vive nas estruturas externas (infra). Só a infra pode depender do core, e apenas via contratos (gateways ou interfaces).

Por que “Conceito-chave: Fluxo de Dependência é do Exterior para o Centro” importa neste artigo?

Seu core expõe contratos (interfaces), mas nunca chama infraestrutura diretamente. Externos acessam internos, jamais o contrário.

Perguntas frequentes

O que “Pasta não define arquitetura” explica de concreto?

O jeito como você nomeia pastas diz pouco sobre a arquitetura do projeto. O que realmente importa é a separação entre regra de negócio (domínio) e detalhes de implementação.

Qual takeaway prático de “Arquitetura Limpa: o Círculo Central Tem Blindagem Total”?

Em Clean Architecture, a camada mais importante é o domínio (core): entidades, regras, casos de uso e contratos com o mundo externo. Tudo ali dentro precisa funcionar sem depender de framework, banco de dados ou biblioteca externa.

O que o texto diz sobre Framework e Infraestrutura: Só na Periferia?

Tudo que é detalhe técnico – banco, JPA, REST, validação, anotações – vive nas estruturas externas (infra). Só a infra pode depender do core, e apenas via contratos (gateways ou interfaces).

Por que “Conceito-chave: Fluxo de Dependência é do Exterior para o Centro” importa neste artigo?

Seu core expõe contratos (interfaces), mas nunca chama infraestrutura diretamente. Externos acessam internos, jamais o contrário.

Como Liga Tudo: Controllers e Adaptadores Só na Periferia

Controllers, endpoints, jobs e outros tratadores externos ficam fora do domínio. Eles apenas instanciam ou executam casos de uso via gateways, nunca acessando entidades de frameworks diretamente.