Clean Architecture é uma arquitetura que mantém o foco no domain. Seu objetivo principal é isolar e manter independência do domínio. A Clean propõe que o domínio (domain) nunca deve depender de detalhes externos.
O conceito foi baseado nas boas práticas e nas arquitetureas hexagonal e cebola, dentre outras, que já propunham a separação das responsabilidades em camadas e tinham como objetivo produzir sistemas com as seguintes características.
Isto é:
A princípio essa arquitetura possui 4 camadas mínimas, o número suficiente manter o isolamento funcional (apesar de não haver restrição de número máximo).
No centro da arquitetura, temos as classes responsáveis pelas regras de negócios, que podem ser dois tipos: Entidades e Casos de Uso.
Entidade: conjunto de regras de negócios relacionadas que são críticas para o funcionamento do aplicativo.
Como as entidades não conhecem as outras camadas elas não dependem de nada
Nessa camada contém as regras de negócio específica do aplicativo. Dizem como automatizar o sistema determinando o seu comportamento.
Alguns exemplos de casos de usos são:
Como vimos na imagem acima, os casos de usos interagem e dependem das entidades, mas não sabem nada mais sobre as camadas mais distantes.
Na terceira camada a partir do centro, temos classes e interfaces chamadas de Adaptadores. A função dela é converter os dados de um formato para outro. São os tradutores entre domínio e a infraestrutura.
Eles convertem os dados do formato mais convenientes para os casos de usos e entidades
Esssa é a camada que vai conter a implementação MVC de uma UI com apresentadores, vizualizações e controladores, ou que poderá realizar a implementação dos endpoints de uma API REST
Nenhum código dentro desse círculo deve saber absolutamente nada sobre o banco de dados
Essa camada é para onde vão todos os componentes de entrada ou saída (input, output), a interface com o usuário (UI), o banco de dados, os frameworks, os dispositivos, etc.
Essa camada é para onde vão todos os detalhes como as interfaces e banco de dados. Ela é a camada mais volátil, pois pode mudar com frequência. E por isso, essa camada é mantida o mais longe possível das camadas de domínio.
Como elas são mantidas separadas, é fácil fazer alterações ou trocar um componente por outro. (por exemplo UI, banco de dados, estruturas e dispositivos)
Desse modo, podemos dizer que
As camadas internas são mais estáveis
As camadas externas são mais sujeitas a mudanças
As entidades raramente devem ser modificadas
Alterações nos Use Cases não devem ser motivadas por mudanças na tecnologia, banco de dados, frameworks, etc.
A Regra de dependência garante que as entidades e os casos de usos sejam classes limpas de qualquer tecnologia ou serviço externo ao sistema
**The Dependency Rule.** Essa é a regra de ouro dessa arquitetura: Dependências sempre apontam para dentro. Ou seja, a camada interna nunca depende de uma externa.
A Clean Architecture não é um substituto do DDD, ela é na verdade uma arquitetura que facilita o DDD.
Desse modo, podemos afirmar que o DDD define o que modelar (o negócio), e a Clean define como organizar (a arquitetura protege o negócio)
Como já vimos na teoria tudo começa pelo domínio, e as dependências sempre apontam para dentro. O fluxo existe para garantir que as dependências sempre apontem para dentro, mas nunca ao contrário. É o que Uncle Bob chama de Dependency Rule. Então, abaixo mostrei o fluxo de execução conceitual e das dependências.
Quando o sistema roda, o fluxo natural de execução é:
Usuário → API → Application → Domain → Infrastructure
ou, em palavras:
Então o fluxo de execução vai “pra baixo” — mas o fluxo de dependência vai pra dentro.
Agora o segredo:
Mesmo que o fluxo de execução vá da API → Infra, o código e as referências entre projetos apontam no sentido oposto:
MyApp.Api ──→ MyApp.Application ──→ MyApp.Domain
↑
│
MyApp.Infrastructure (implementa interfaces)
A API conhece a Application, porque chama os Use Cases.
A Application conhece a Domain, porque usa as Entidades.
Mas nenhuma das duas conhece a Infrastructure —
apenas definem interfaces (ex: IPedidoRepository).
A Infrastructure é quem conhece as outras, porque precisa:
IPedidoRepository;DependencyInjection).então, resumidamente, as dependências possuem esse tipo de papel:
| Camada | Papel | Depende de |
|---|---|---|
| Domain | Regras puras (núcleo) | Ninguém |
| Application | Usa as regras do domínio | Domain |
| API (ou UI) | Mostra o sistema pro mundo | Application |
| Infrastructure | Conecta o sistema ao mundo real | Domain + Applicatio |
Geralmente a solução .sln fica assim:
CleanOrders/
│
├── src/
│ ├── CleanOrders.Domain/
│ ├── CleanOrders.Application/
│ ├── CleanOrders.Infrastructure/
│ └── CleanOrders.Api/
│
├── tests/
│ ├── CleanOrders.UnitTests/
│ └── CleanOrders.IntegrationTests/
│
└── CleanOrders.sln