Clean Architecture e suas premissas
No início do projeto, e também durante sua evolução, é normal existir uma grande preocupação com a arquitetura, pois ela é uma das peças mais importantes, afinal, ela define os componentes e seus relacionamentos, constituindo assim, o fluxo de funcionamento do sistema.
Por conta disso, Robert C. Martin, mais conhecido como Uncle Bob, propôs um estilo de arquitetura chamado Clean Architecture (Arquitetura Limpa), onde as diferentes partes do sistema, possuem um baixo grau de dependência, ou seja, fraco acoplamento, resultando em uma fácil manutenibilidade e testabilidade.
Esse estilo foi derivado de outras idéias arquiteturais existentes, dentre elas a Arquitetura Cebola e Arquitetura Hexagonal que em sua essência, compartilhavam idéias similares.
As premissas do Clean Architecture são:
- Independência de Framework: A arquitetura não deve depender de algum Framework específico, ou seja, somente devem ser utilizados como ferramentas.
- Testabilidade: As regras de negócio podem ser testadas de maneira independente, e não devem depender de nenhum outro elemento.
- Independência de Interface de usuário: A interface do usuário ou Front-end deve ser independente e não deve interferir no funcionamento do sistema.
- Independência de banco de dados: A arquitetura não está atrelada a um banco de dados específico, com isso, podemos trocar o banco de dados com facilidade e sem afetar as regras de negócio do sistema.
- Independência de agentes externos: A regra de negócio do nosso sistema não deve depender de nenhum elemento externo.
Antes de prosseguirmos, vamos relembrar um pouco dos conceitos de acoplamento e coesão, que estão diretamente ligados ao Clean Architecture.
Acoplamento
Quando as diferentes partes que compõe um software possuem um alto grau de dependência, dizemos então que possui um alto acoplamento. Isso afeta a manutenção e testabilidade do sistema. Outro ponto é a dificuldade de realizar mudanças ou ajustes no comportamento do sistema.
Coesão
Termo designado para as responsabilidade de cada parte do sistema. Quando uma parte do nosso sistema, realiza diferentes tarefas, conceitualmente, possui uma baixa coesão.
Um sistema bem estruturado possui baixo acoplamento e alta coesão, portanto, uma das soluções encontradas é a divisão do sistema em camadas, conforme imagem abaixo:
Entidade/Entities: Lugar onde ficam os objetos de domínio, regras de negócio, contratos de serviços e outras funções referentes a manipulação de dados do sistema.
Casos de uso/Use cases: Nessa camada estão os objetos que representam uma ação dentro do sistema, sendo chamados de casos de uso. Esses casos de uso realizam a orquestração de fluxo de dados, ou seja, direcionam os dados para aplicação da regra de negócio, validações e posteriormente para as persistências.
Adaptadores de interface/Interface Adapters: Camada responsável, por realizar a comunicação entre as entidades e os componentes externos da aplicação, como por exemplo, a interface do usuário (UI).
Frameworks e drivers/ Frameworks & Drivers: Camada composta de ferramentas, como por exemplo, o banco de dados.
As dependências de cada parte, segue da camada externa para a camada interna. O inverso não pode ocorrer, ou seja, um caso de uso pode conhecer a entidade que necessita manipular, porém, uma entidade não conhece seus casos de uso.
A imagem mostrada acima é constituída de 4 camadas, mas isso não é regra, tudo depende da necessidade do seu projeto, portanto, podemos ter mais ou menos camadas.
Com isso, podemos notar que existe grandes benefícios em sua utilização, dentre eles:
- Flexibilidade
- Testabilidade
Outro grande benefício, é a possibilidade de substituir facilmente os elementos do sistema, quando os mesmos se tornarem obsoletos.
Portanto, seguindo os premissa do Clean Architecture, construímos um software totalmente testável, onde cada componente possui um baixo nível de dependência e responsabilidades únicas, transformando a arquitetura flexível para mudanças.
Até mais!
