Arquitetura limpa - Clean Architecture

Eficiente quando aplicada em softwares de grande porte que necessitam de manutenção ao longo prazo. Criada em 2012 por Robert Martin.

Categoria de Programação

Postado em 24 fevereiro 2022

Atualizado em 07 junho 2023

Palavras-chave: clean,architecture,uncle,tio,bob,tutorial,arquitetura,limpa,ddd

Visualizações: 3237

A maioria dos softwares usam a arquitetura MVC (model view controller). O MVC tem as suas vantagens. Softwares de porte pequeno com necessidade de rápido desenvolvimento podem optar pelo MVC. Porém, essa arquitetura também tem as suas desvantagens. Projetos de grande porte que usam a arquitetura MVC, provavelmente vão ter alguns problemas ao longo prazo na realização da manutenção. O forte acoplamento entre as classes faz com que o software seja difícil de modificar ou adicionar novas funcionalidades. O termo “difícil” quer dizer mais demanda de tempo para realizar uma tarefa. Quanto mais tempo os desenvolvedores necessitam para implementar novas funcionalidades ou para fazer modificações, mais custos essa tarefa terá para a empresa que paga os seus funcionários.

Felizmente, existem outros tipos de arquitetura de software que são eficientes no quesito de manutenção. Quanto mais eficiente for a manutenção, menor serão os custos. A arquitetura limpa (clean architecture) é uma boa arquitetura para projetos de porte grande que irão demandar manutenções frequentes no futuro.

O que é a arquitetura limpa?

Arquitetura apresentada pela primeira vez em 2012 por Robert Martin, em seu blog. Em 2018, Robert Martin lança o livro sobre a arquitetura limpa como solução para softwares frágeis a manutenção, ganhando atenção de muitos desenvolvedores e diretores.

A arquitetura limpa é composta por vários princípios. Alguns princípios foram criados por Robert Martin, outros foram de autoria de outros programadores experientes. Ao todo existem 11 princípios abordados:

  • Princípios SOLID (5 princípios)
  • Princípios RCC (3 princípios)
  • Princípios ASS (3 princípios)

Além de abordar como o código deve ser escrito, a arquitetura limpa também fala como os componentes (conjunto de classes) devem ser agrupados, analisando a estrutra do nível de código e do nível arquitetural.

A regra de dependências é essencial na arquitetura limpa. Detalhes devem depender de abstrações, mas abstrações não devem depender de detalhes. O objetivo da arquitetura limpa é proteger os componentes de nível alto dos componentes de nível baixo. A proteção é feita usando a hierarquia de dependências em níveis, onde os componentes de nível baixo devem depender dos componentes de nível alto. Essa prática possibilita a reutilização de componentes e a substituição de detalhes por outros, uma vez que os componentes não sabem nada sobre os detalhes de nível baixo.

arquitetura limpa hierarquia de proteção em níveis

Na imagem acima, o nível 1 é a camada mais protegida, pois ela não depende de ninguém. A camada no nível 2 depende do nível 1 e pode sofrer influências caso algo na camada de nível 1 seja modificado. A camada de nível 3 depende da camada de nível 1 e 2, podendo sofrer influência. A camada de nível 4 é a camada mais detalhada, podendo sofrer influência de qualquer camada.

No exemplo acima de hierarquia de camadas em níveis, Robert Martin diz que o número de camadas pode ser maior ou menor dependendo das exigências do software. Contanto que as regras de negócio estejam protegidas dos detalhes não há violação.

Os detalhes são responsáveis por usar banco de dados, adotar frameworks e usar bibliotecas terceirizadas. As regras de negócio jamais deve usar frameworks ou banco de dados diretamente. O uso de bibliotecas nas regras de negócio só é permitido se a biblioteca não possui uma alta volatilidade (mudar com frequência). Queremos proteger componentes de alto nível de modificações externas. Já os detalhes podem ser substituídos quando necessário, por isso não há preocupação em proteger os detalhes de componentes voláteis.

Como aplicar a arquitetura limpa?

A arquitetura limpa usa vários princípios dizendo como arquitetar o software. Os princípios que atuam no nível do código são os princípios SOLID:

  1. Princípio de responsabilidade única
  2. Princípio aberto fechado
  3. Princípio de substituição de Liskov
  4. Princípio de segregação de interfaces
  5. Princípio da inversão de dependências

Os princípios SOLID são 5 princípios que dizem como devemos estruturar o código. São o requerimento mínimo para que a arquitetura limpa possa ser aplicada corretamente.

Além dos princípios SOLID, existem os princípios RCC e ASS que atuam no nível de arquitetura e dizem como devemos agrupar e conectar os componentes. O RCC possui 3 princípios:

  1. Princípio equivalente de reúso/release (REP)
  2. Princípio de fechamento comum (CCP)
  3. Princípio de reúso comum (CRP)

Os três princípios acima dizem como os componentes devem ser agrupados coesivamente. Pelo fato de ser impossível agrupar os componentes perfeitamente, o princípios RCC traz um triângulo de tensão para coesão de componentes mostrando o que acontece com o software dependendo da localização dele.

arquitetura limpa triângulo de tensão de coesão em componentes

Muita gente deve imaginar que a melhor posição no triângulo acima é no centro. Porém, isso depende do estágio do projeto. Geralmente o projeto começa no lado direito do triângulo e vai mudando para o lado esquerdo conforme o projeto amadurece.

Os princípios ASS dizem como os componentes devem ser ligados uns aos outros, abordando sobre as dependências entre componentes. O ASS possui três princípios:

  • Princípio das dependências acíclicas (ADP)
  • Princípio das dependências estáveis (SDP)
  • Princípio das abstrações estáveis (SAP)

A dependência entre componentes deve ser planejada estrategicamente para facilitar o teste e a manutenção de modo isolado.

Todos os onze princípios abordados na arquitetura limpa são de extrema utilidade para melhorar a manutenção ao longo prazo. Há quem selecione apenas alguns desses princípios para aplicar na prática. Dependendo do contexto do aplicativo, aplicar apenas uma porção da arquitetura limpa também é válido. Desenvolver o software sabendo das consequências é o mais importante.

Conclusão

A arquitetura limpa é um conjunto de princípios que dizem como o código deve ser implementado para manter a produtividade do projeto alta ao longo prazo. Em algumas ocasiões a arquitetura limpa pode apresentar desvantagens, como por exemplo em um projeto de porte pequeno que necessita de velocidade no desenvolvimento. Porém, é extremamente eficiente na manutenção do software.

Projetos práticos

Criando o esqueleto de um jogo de tiro 2D visto de cima usando P5.js

Usando lógicas matemáticas como trigonometria para criar e calcular o esqueleto de um jogo de tiro 2D em javascript

Desenvolvendo um jogo de quebra blocos em javascript

Programando um jogo clássico de arcade usando javascript e p5.js. O usuário deve quebrar os blocos utilizando uma bola ao mesmo tempo que evita que a bola saia pela parte inferior da tela

Criando um sistema de integração contínua (CI/CD)

Fazendo a integração contínua de Jenkins, Sonatype Nexus, Sonatype, JUnit e Gradle para automatizar processos repetitivos. Prática bastante usada em tecnologias de DevOps.

Desenvolvendo o campo de visão de um personagem em um plano 2D

Detectando objetos que entram dentro do campo de visão do personagem. Útil para servir de "gatilho" para eventos em um jogo.

Implementando um algoritmo de pathfinding

Implementando um programa que encontra a menor distância entre dois pontos dentro de um labirinto usando o algoritmo A* (a-estrela).

Veja também

Afinal, para que servem os cookies que sempre são solicitados quando entramos em uma página?

A política de privacidade é obrigatória para qualquer site que utiliza dados pessoais do usuário. Porém, quais dados são esses especificamente?

Estar antenado pode te salvar de cair em algum golpe

A engenharia social é a forma mais fácil de roubar os dados da vítima, principalmente aqueles que não estão antenados..

PPM Product Portfolio Management

Em português, gestão de portofólio de produto. É uma estratégia de análise utilizada para a distribuição de recursos para um produto ou serviço.

Ativação de produto

O código de ativação de softwares tem como objetivo prevenir a pirataria e revenda de produtos sem o conhecimento e autorização do autor.

Hub, Switch e Roteador

Se destacam o hub, switch e o roteador como dispositivos que possibilitam o estabelecimento de uma rede local. Cada dispositivo possui suas vantagens.

Princípio de segregação de interfaces - Interface Segregation Principle

Os clientes não devem ser forçados a importar métodos que eles não usam. Os métodos devem ser segregados de modo abstrato em interfaces.