No meu último artigo aqui no blog da Taller começamos uma breve introdução sobre Arquitetura de Software e conversamos um pouco mais sobre Arquitetura Gritante e Padrões Arquiteturais, então antes de começar a ler este artigo eu sugiro que você dê uma conferida naquele post. Mas agora continuamos e vamos falar sobre um assunto mais específico. Neste artigo vamos falar especificamente do Clean Architecture (que eu tanto amo!) espero que vocês curtam e que role uma troca bacana! Bora lá!
Clean Architecture
De forma bem resumida, a Clean Architecture foi criada pelo famoso Robert Cecil Martin, mais conhecido como “Uncle Bob” (tio Bob), em meados de 2012. Ele publicou diversos livros, e muito bons diga-se de passagem, na área de engenharia e arquitetura de software:
Depois que li esses livros, a minha mente simplesmente se abriu para um monte de coisas boas, coisas que me fizeram amadurecer como desenvolvedor e que pretendo mostrar nessas série de posts. E na minha humilde opinião, eu acho que TODO(A) DESENVOLVEDOR(A) que esteja buscando elevar seu nível, digamos assim, deve ler esses 2 livros para ter uma baita mudança de mindset, fica a dia!
Objetivos
Voltando a falar do Clean Arch (apelido carinhoso), abaixo vou mostrar os principais objetivos desse padrão arquitetural:
Independência de Frameworks:
A arquitetura não depende da existência de bibliotecas de software. Isso faz com que você use esses frameworks como ferramentas ao invés de ser obrigado a adaptar o seu sistema às limitações do framework;
Testabilidade:
Testes de softwares independente de UI, SGBD’s, servidores web ou qualquer tipo de agente externo;
Independência da UI:
A UI é algo muito fácil de mudar, e se for mudado para uma UI de Console, por exemplo, não deverá afetar as suas regras de negócio;
Independência de Banco de Dados:
Sei que isso é algo bem difícil de acontecer, mas caso aconteça, você poderá trocar facilmente o seu principal SGBD por um outro, pois o seu banco de dados não vai ter relação nenhuma com suas regras de negócio. Papel do banco de dados é armazenar dados;
Independência de QUALQUER agente externo:
Sabe aquele pacote de formatar moedas maneira do fulano, e aquele outro pacote que faz envio de e-mails de forma fácil? Então, suas regras de negócio nem sabem que elas existem, pois elas não estão “dentro do mundo” das suas regras de negócio;
Nota-se que a palavra “independência” foi usada frequentemente acima, e o grande objetivo desse modelo de arquitetura é exatamente suas regras de negócio serem independentes e desacopladas.
Famoso Diagrama da Arquitetura Limpa
Abaixo vocês vão ver um diagrama super conhecido pelos amantes de clean architecture e eu vou explicar da forma mais simples e menos acadêmica possível para que fique bastante claro a responsabilidade de cada camada:
Existem algumas derivações deste mesmo diagrama, como este em formato de cone:
Antes de falar de cada camada especificamente, preciso falar algumas considerações gerais:
- Cada círculo desses representa uma área da sua aplicação;
- Quanto mais externo (mais nas extremidades), mais representaram mecanismos e detalhes do seu software. Por exemplo, no círculo azul você terá: banco de dados, UI, bibliotecas de terceiros, frameworks e etc. Sim, isso tudo é detalhe e você não deve depender deles!
- Quanto mais interno (adentrando no círculo), mais representaram políticas, protocolos, abstrações, contratos e etc;
- Você tem sempre que se atentar nessa arquitetura nas Regras de Dependências, perceba no diagrama que existem 3 setinhas pretas apontando SEMPRE para dentro do círculo. Isso mostra que as dependências devem sempre vir de fora pra dentro e NUNCA de dentro para fora;
- O que tiver dentro do círculo mais INTERNO não pode saber nada do que tem nos círculos mais EXTERNO. Por exemplo, a camada/círculo Entities NUNCA saberá o que tem lá na camada DB, Controllers, Web e etc;
Se vocês conseguiram pegar a ideia destes conceitos mais gerais, então, vamos agora falar um pouco de cada camada:
Entidades (Entities)
Suas entidades representam seus objetos de domínio, elas reúnem as Regras Cruciais de Negócios da aplicação como um todo. Elas podem ser objetos com métodos ou um conjunto de estrutura de dados e funções.
De forma resumida, aqui estarão os objetos de negócios da aplicação onde estarão as regras mais gerais e de mais alto nível da sua aplicação. Essa camada tende-se a ser umas das que raramente serão alteradas durante a vida do software.
Importante: Objetos puros! Sem framework, sem annotations!
Casos de Uso (Use Case)
Seus casos de uso são ações do seu negócio, nelas você terá as Regras de Negócio Específicas da sua aplicação. Esses casos de uso orquestram o fluxo de dados a partir das Entidades, e orientam as mesmas para execução de alguma funcionalidade da sua aplicação. As mudanças nessa camada não devem afetar em absolutamente nada na camada Entities!
É aqui nessa camada onde você irá descrever alguma funcionalidade da sua aplicação. Vamos supor que estamos trabalhando na criação de um usuário na aplicação. Teríamos um caso de uso específico para isso, onde você fará a “dança das entidades” e irá implementar toda regra necessária para criação de um usuário.
Importante: os casos de uso não sabem e nem precisam saber quem o disparou/chamou ou como deve ser a saída dele (JSON, XML, CSV, HTML e etc)
Adaptadores de Interface (Interface Adapters)
Nessa camada nós teremos adaptadores que devem converter os dados no formato que seja mais conveniente para as camadas de Use Case e Entities como também para os agentes externos, como Banco de Dados, Web e etc.
É muito comum o uso de DTO’s nessa camada para fazer essa transferência de dados entre camadas. E aqui nessa camada onde temos o uso do famoso Controller e também da arquitetura MVC caso seja necessário.
Essa camada é quem faz o meio de campo entre as camadas mais internas para as mais externas. Ela quem vai saber qual o melhor formato de dado para Entities e Use Cases como também é ela quem sabe qual o melhor formato de dado para Banco de Dados, Web, Console e qualquer outro agente externo.
Frameworks e Drivers
Essa é a camada mais externa da arquitetura, lá deverá ter todos os detalhes da sua aplicação como: banco de dados, bibliotecas de terceiros e frameworks. Vai ser bem raro, ou nunca, programar nessa camada, você vai sim escrever componentes de associação entre esses mecanismos e a camada/círculo mais interno seguinte.
Conclusão
Enfim, chegamos ao final desse overview, e não se enganem! Esse assunto dá muita margem para interpretação e ela por si só não é a verdade absoluta para todas as situações, ok?!
Por experiência própria, é preciso em alguns momentos abrir mão de algumas coisas para ganhar em outras, mas isso eu só poderia mostrar em um post mais prático.
E caso vocês queiram que eu faça algo mais prático sobre Clean Architecture, comentem aqui no post dizendo o que vocês acharam, dúvidas e também o quanto vocês querem ver algo mais prático. De toda forma, deixarei aqui alguns repositórios do github de algumas implementações da Clean Architecture para sua apreciação.
Um forte abraço.
Repositórios GitHub:
Referências: