cleanarchimage

Clean Architecture

Written by:

Criada por Robert C. Martin (Uncle Bob) 2012

Quando falamos de arquitetura limpa estamos falando em como criar um modelo de design de aplicação de modo que eu consiga proteger o core do meu negócio, isolando essa camada das camadas mais externas que tendem a variar mais frequentemente com o tempo. Esse design cria uma divisão de componentes.

Esses componentes precisam se comunicar entre eles.

A arquitetura limpa é caracterizada por uma estrutura em camadas, onde as dependências entre as camadas são sempre de baixo para cima (das camadas externas para as internas).  

Quando devemos usar? Esse modelo de design nos obriga a implementar essas camadas de proteção ao core da aplicação.

Por esse motivo, usar CA (Clean Architeture) em todo projeto, principalmente projeto pequenos, micro serviços, simples, com equipes pequenas nem sempre é o melhor caminho.

Como desenvolvedores temos sempre a inclinação de querer usar toda a novidade que o mercado aborda, porém, é um erro.

Devemos buscar usar CA em projetos complexos, quando precisamos e devemos proteger a camada de negócio por ser grande e complexa demais, e por ser assim, exige essa proteção, pra facilitar o desenvolvimento em grande escala, facilitando a testabilidade e manutenção da aplicação. Usar esse padrão em todos os projetos irá aumentar a complexidade da sua aplicação desnecessariamente. Dito isso, aqui está o diagrama mais comum da CA.

Esse desenho simples é uma representação de como funciona a comunicação entre os componentes da Arquitetura.

Repare que temos 3 camadas bem definidas, Application, Domain e Infra.

A camada de Domain contêm todas as regras e funcionalidades do domínio da nossa aplicação, vou colocar um exemplo de como devemos construir nossa estrutura.

Vamos para um exemplo prático.

Vamos criar uma classe para representar uma entidade no nosso sistema:

Então temos aqui um módulo de Domain com uma classe Account que representa uma entidade.

Vamos criar agora os comandos que essa entidade aceita, nesse caso permitiremos mudança de profile, email e documento.

Agora vamos criar um gateway para as camadas de Application e Infrastucture conseguir se comunicar com nosso Domain

Como a camada de domínio não pode ter nenhum framework como o spring por exemplo, temos q ter um identificador para nossa entidade.

Agora vamos definir oq é uma entidade:

Com isso temos o básico pra nossa camada de Domain, poderíamos ainda criar os Handlers pra lidar com lançamento de excessão, Validators, etc.

Vamos criar agora nossa camada de Application. Nessa camadas criaremos a definição básica de UseCase, que pra clean arch é um dos conceitos que definem as funcionalidades que nosso sistema comporta.

A ideia aqui é que todo caso de uso tem uma entrada (IN) e uma saída (OUT) ou casos de uso apenas com entrada.

Com a abstração do UseCase podemos definir a abstração do caso de uso pra criar a Account

Aqui demonstramos que nosso caso de uso CreateAccount tem esse input e output. Obrigando quem implementar esse contrato utilizar esse formato.

Agora vamos implementar de fato esse usecase:

Note que aqui injetamos o nosso gateway do Domain pra ter acesso ao método save.

Agora é onde as coisas se conectam.

Na camada de Infrastrure precisamos implementar de fato a persistência. Aqui dependemos de framework, de banco de filas, então como o domínio determina, “Ei, salva uma account ai pra nós”, a infra realiza a função que é intermediada pelo caso de uso. Note:

Aqui implementamos o Gateway e damos acesso as camadas externas, usuários externos, sistemas a toda nossa lógica.

Podemos inclusive ter uma outra implementação do mesmo Gateway para persistir em memória.

Essa é a ideia principal do design de clean arch.

Lembre-se de quando for criar um projeto evite separar essas camadas apenas por pastas, o ideal é criar módulos e fazer com que o Domain não dependa de módulo nenhum, o Application dependa do Doman e Infra do Application. Assim você protege as camadas e impede que desenvolvedores inexperientes quebrem as camadas com comunicação indevida.

repositório publico temporariamente.

git@github.com:velkanknight/hexagonal.git

Deixe um comentário


    Descubra mais sobre CodaCodeTech

    Assine para receber nossas notícias mais recentes por e-mail.

    Deixe um comentário

    Latest Articles