Executando verificação de segurança...
6

Arquitetura Limpa

Quando surgiu arquitetura de software?

Apesar de se tornar popular nos anos 90, como conceito teve seu inicio na década de 60 com Edsger Dijkstra, um cientista da computação holandês, que ganhou o prêmio Turing em 1972 e posteriormente o prêmio Dijkstra em 2002, nessa época cientistas já discutiam arquitetura de software, dando ênfase a importância de estruturar um sistema antes de começar seu desenvolvimento.

O que é arquitetura de Software?

A estrutura de um software, com foco em como os componentes de um sistema interagem entre si, possibilitando então que qualquer componente tecnológico possa ser usado para integrar uma solução arquitetural, mostrando-se essencial para a otimização do trabalho de desenvolvedores e designers, garantindo os padrões básicos necessários para um funcionamento de forma assertiva, diminuindo assim os riscos associados ao sistema.

Len Bass 2003: é a estrutura (ou estruturas) do sistema, a qual é composta de elementos de software, das propriedades externamente visíveis desses elementos, e dos relacionamentos entre eles, é a abstração do sistema.

ISO/IEEE 1471-2000 - Arquitetura é a organização fundamental de um sistema incorporada em seus componentes, seus relacionamentos com o ambiente, e os princípios que conduzem seu design e evolução.

No final das contas é uma forma de conseguir compreender os atributos e limitações de um negocio/empresa, e tendo isso como base, trazer o software pelo menor valor possível e no menor tempo possível, além de torna-lo sustentável, estando pronto para comportar qualquer mudança da melhor forma possível, para que a solução possa continuar sendo evoluída.

Atualmente, com a diversidade de princípios e padrões que são utilizados nos sistemas, não vemos uma restrição em relação ao uso de um único estilo ou arquitetura, pelo contrario, são uma combinação de padrões que, juntos, formam o sistema completo.

A arquitetura de software envolve:

  • Controle;
  • Protocolos de comunicação, sincronização e acesso de dados;
  • Decidir as estruturas que irão formar o sistema, etc...

Clean Architecture

Robert Cecil Martin

Robert Cecil, popularmente conhecido como "Uncle Bob", nasceu em 1952 na Califórnia, e atua como software professional desde 1970. Escreveu livros sobre UML, OOP, C++, além de publicar dezenas de artigos.

Como surgiu?

Micah Martin, desenvolvedor de software e filho de Uncle Bob, estava mostrando a ele a estrutura de diretórios de um projeto em que estava atuando. Após analisar a estrutura, ele conseguiu determinar que a tecnologia utilizada no projeto era Ruby on Rails. Posteriormente, em uma apresentação que estava fazendo, ele mostrou a arquitetura de uma igreja que era em formato de cruz, a propria arquitetura gritava a intenção do sistema. E isso deixou o Robert muito incomodado, dando início a criação da Arquitetura Limpa ou Clean Architecture, promovida em seu livro "Clean Architecture: A Craftsman’s Guide to Software Structure".

Ideias e objetivos

Robert propôs o design da arquitetura limpa para servir como um modelo para sistemas modulares. Tendo como objetivo criar uma arquitetura de camadas simplificada, fornecendo aos desenvolvedores uma metodologia que visa facilitar o desenvolvimento, manutenção, extensão e atualização do código, assim como diminuir as dependências, permitindo então que o sistema seja ágil a mudanças, conforme as necessidades que surgem durante o amadurecimento do software.

Como Funciona?

Se tratando de uma arquitetura Domain-Centric, isto é, entende que a razão da existência de
um software é o domínio, colocando ele no centro. A arquitetura limpa visa isolar o core da
aplicação do mundo externo a partir do uso de camadas, seguindo o principio SoC, de forma
que cada um dos seus componentes possui suas próprias responsabilidades e cada uma delas
tem conhecimento apenas de camadas de dentro.

Mark Seeman "de forma que cada um dos seus componentes possui suas próprias responsabilidades
e cada uma delas tem conhecimento apenas de camadas de dentro."

Na arquitetura limpa o fluxo de dependência entre as camadas, centraliza a camada de domínio,
tornando possível projetar aplicativos com menor acoplamento e independentes de detalhes
técnicos de implementação, como bancos de dados e estruturas. 

Camadas

Entidades

Camada que encapsula as entidades (classes comuns a vários sistemas da empresa) e regras de negócio, contendo as regras que tem a menor possibilidade de mudança devido a alterações externas, como algo na interface.

Use Case

Esta camada fica com as regras de negocio mais especificas de um sistema, sendo responsável
pela forma como o sistema é utilizado por uma pessoa ou client.

Adaptadores

Esta camada é responsável pela conversão dos dados vindos das camadas mais internas, mediando
a interação entre a camada mais externa da arquitetura e as camadas centrais, contendo por
exemplo gateways e DTOs.

Frameworks

Aqui ficam os elementos externos, como por exemplo: Frameworks, Banco de dados, e quaisquer
sistemas externos.

Vantagens

Testes

Facilidade para testar o código, a clean architecture preza que o núcleo não dependa de nada, o que torna possível testa-lo sem depender de qualquer outro elemento externo (interface, banco, servidor...).

Flexibilidade

Alterações em camadas externas não afetam o core da aplicação, pois ele é independente de qualquer agente externo, de forma que suas regras de negócio não conhecem o mundo exterior.

Desvantagens

Curva de Aprendizagem

Possui uma curva de aprendizado íngreme, principalmente para devs que vem de padrões mais simples(MVP, MVVM...), exigindo tempo e dedicação para entender seus conceitos.

Muitas Classes

Essa arquitetura usa um grande número de classes adicionais, um esforço necessário para tornar nosso código desacoplado e generalista, o que torna a aplicação apta para receber substituições sem impactar o nosso domínio, fazendo com que este modelo não seja o ideal para projetos de baixa complexidade.

Links para se aprofundar

Vídeos

Clean Architecture (Arquitetura Limpa) // Dicionário do Programador
45 - Clean Architecture
O que é Clean Architecture?
Clean Architecture
REST, GraphQL, Clean Architecture e TypeScript com Rodrigo Manguinho // Live #69

Artigos

The Clean Architecture
Descomplicando a Clean Architecture
Clean Architecture: o que é, vantagens e como utilizar em aplicações na prática

Considerações finais

Minha intenção era sintetizar informação sobre a tão falada Clean Architecture de modo a auxiliar quem esteja no processo de aprendizado, espero que eu tenha conseguido ajudar alguém :)

Feedbacks

Estou aberto a feedbacks, correções de informações erroneas e a bater um papo:
Meu Linkedin

Um abraço!

Carregando publicação patrocinada...
2

Artigo muito interessante BreninCD, obrigado por compartilhar!

Clean Architecture é um caso bem interessante de uma frase que minha esposa fala com uma certa frequencia: "Não é porque você pode, que você deve" - Souza, Camila

Não nego que é um tipo de arquitetura muito interessante e que realmente ajuda a tornar as coisas mais testáveis, mas ficar preso a ela pode gerar um problema muito grande de negócio.

Veja só, muitas vezes no dia a dia de uma empresa você precisa lançar algo extremamente rápido para validar com seu cliente e ver se aquele produto tem market fit, e implementar tudo numa abordagem clean architecture, pode fazer você perder o timing.

Já trabalhei como Tech Lead numa startup onde os devs eram malucos pela Clean Architeture, e era um sofrimento pra lançar qualquer coisa.

Tem um vídeo do canal Dev Eficiente que aborda mais profundamente os motivos do porque em 99% dos casos você NÃO DEVE USAR clean architecture.

Clean Architecture: Provavelmente você não quer isso
https://www.youtube.com/watch?v=SQfpiDlYd0g

No mais, é excelente que devs iniciantes aprendam. Ela abre a mente para muitas formas de desacoplamento, mas usar em TUDO que você tem que programar é um tiro no pé.

1

Obrigado pelo comentário bgabraga!

E muito obrigado tbm por disponibilizar um outro ponto de vista acerca do assunto!

Após ler seu comentário e assistir o vídeo do Dev Eficiente consegui levantar alguns pontos, vou deixar minha opinão sobre os mesmos:

1 - Eficiência:

De fato, quando estamos falando de lançar um produto num curto espaço de tempo para validação, a arquitetura limpa pode ir contra a maré, mas acredito tbm que essa eficiência se pague ao longo do desenvolvimento, depois de um tempo codando conseguimos reutilizar muitas coisas que já foram feitas de uma forma segura.

2 - Microsserviços:

Devo admitir que sei pouco sobre esse assunto, então optei por deixar um vídeo que aborda o assunto e as experiências de grandes de empresas com a atilização de clean arch e microsserviços em conjunto:

188 - Arquitetura Limpa num mundo de MICROSSERVIÇOS? | theWiseDev Clean Architecture

3 - Estabilidade:

Como o próprio Alberto Sousa (Dev Eficiente) falou em seu vídeo:
"... E eu so passei na minha vida inteira, pelos projetos que trablhei e coisa do gênero, e provavelmente eu trabalhei em menos projetos talvez do que você está me vendo aqui no vídeo, mas a minha experiência é, eu passei por 1 projeto que a tecnologia ficou obsoleta e gente teve que trocar, esse projeto foi o projeto da alura..."

Trecho citado: Clean architecture: Provavelmente você não quer isso - 4:52

Eu acredito que se proteger em relação ao tempo e tecnologias obsoletas é uma medida que vale a pena ser tomada, tendo em vista que as evoluções e atualizações tecnológicas estão acontecendo em uma velocidade cada vez maior, por mais que seja pequena a probabilidade, se uma determinada tecnológia se tornar incoerente a necessidade da nossa aplicação devemos ser capazes de substituir a mesma, com a maior agilidade e segurança possível

Agradeço mais uma vez por compartilhar sua opinião e experiência, me fez pensar, refletir e enxergar o outro lado da moeda "Arquitetura Limpa", muito obrigado!

1
1

Parabéns pelo artigo, além de ter escrito tão bem, ainda encheu de referências.

Sobre:

[...] fazendo com que este modelo não seja o ideal para projetos de baixa complexidade.

Muito bom esse ponto. Já vi projetos reais onde o desenvolvedor tentou aplicar arquitetura limpa em uma aplicação simples, com poucas funcionalidades, resultado: O projeto havia muito mais boilarplate do que lógica de negócio de fato.

1

Obrigado, Fico feliz que tenha gostado!

E sobre o seu ponto, realmente é uma situação comum, devemos sempre estar atentos a realidade do nosso projeto e aos requisitos do mesmo, por vezes utilizamos um canhão para matar mosquitos!

1

Cara, eu agradeço! Materialzin muito bom, bem resumido mas não deixou escapar os pontos, o Tabnews precisa de mais conteudo assim, em vez de post sobre o que alguem perguntou pro ChatGPT...

1
1