Uma breve introdução à arquitetura limpa

Eduardo de Oliveira Machado — Tue, 18 Apr 2023 21:00:00 +0000

Artigo original: A quick introduction to clean architecture

Escrito por: Daniel Deutsch

Em um projeto de código aberto para o qual comecei a contribuir, o conceito de "arquitetura limpa" me foi apresentando.

No começo, era demais para se entender. Após um pouco de leitura, no entanto, passou a fazer sentido. Acho que será de ajuda a outros se eu escrever meus aprendizados.

Tabela de conteúdos

Representações visuais

Eu acho que sempre é bom começar com um pouco de visualização.

Aqui estão as imagens mais comuns deste conceito.

Fonte e créditos: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html .https://www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/

Fonte e créditos: Mattia Battiston, sob a licença Creative Commons BY 4.0, https://github.com/mattia-battiston/clean-architecture-example

Fonte e créditos: https://marconijr.com/posts/clean-architecture-practice/

O conceito — apresentado em tópicos

Estendido da fonte e créditos: Mattia Battiston, sob a licença Creative Commons BY 4.0

O valor que pode entregar

Uma estratégia de teste eficaz que segue a pirâmide de testes
Frameworks são isolados em módulos individuais. Quando mudarmos de ideia, só precisamos mudar uma coisa em um lugar. A aplicação tem casos de uso em vez de estar vinculada a um sistema de CRUD
Arquitetura gritante, ou seja, ela grita seu uso pretendido. Ao olhar para a estrutura, você tem uma ideia do que a aplicação faz, em vez de ver detalhes técnicos
Toda a lógica de negócios está em um caso de uso. Por isso, é fácil de encontrar e não é duplicada em nenhum outro lugar
É difícil fazer a coisa errada, porque os módulos impõem dependências de compilação. Se você tentar usar algo que não deveria, o app não compilará
Sempre pronta para ser implantada, deixando as conexões do objeto para o final. Também é possível usar flags de recursos para obter todos os benefícios da integração contínua
Vários trabalhos em histórias para que pares diferentes possam trabalhar facilmente na mesma história ao mesmo tempo para concluí-la mais rapidamente
Um bom monolito com casos de uso claros que você pode dividir em microsserviços mais tarde, depois de aprender mais sobre eles

Entidades

Representam os objetos do domínio
Aplicam somente lógica que é aplicável em geral à entidade inteira (exemplo: validar o formato do nome de um host)
Objetos simples: sem frameworks, sem anotações

Casos de uso

Representam suas ações de negócio: é o que você pode fazer com a aplicação. Espere um caso de uso para cada ação de negócios
Lógica de negócios pura, código simples (exceto talvez algumas bibliotecas de utilitários)
O caso de uso não sabe quem o acionou e como os resultados serão apresentados (por exemplo, pode ser em uma página da web, retornado como JSON ou simplesmente registrado e assim por diante).
Lançam exceções de negócio

Interfaces/adaptadores

Recuperam e armazenam dados de e para várias fontes (banco de dados, dispositivos de rede, sistema de arquivos, terceiros e assim por diante).
Definem interfaces para os dados que eles precisam para aplicar alguma lógica. Um ou mais provedores de dados implementarão a interface, mas o caso de uso não sabe de onde vêm os dados
Implementam as interfaces definidas pelo caso de uso
Existem maneiras de interagir com a aplicação e, geralmente, envolvem um mecanismo de entrega (por exemplo, APIs REST, trabalhos agendados, GUI, outros sistemas)
Acionam um caso de uso e convertem o resultado em um formato adequado para o mecanismo de entrega
São o controller em um MVC

Interfaces externas

Use qualquer estrutura que seja mais apropriada (elas serão isoladas aqui, de qualquer maneira)

Código de exemplo

Veja este exemplo no GitHub.

Em primeiro lugar, é importante entender que a arquitetura limpa é um conjunto de princípios de organização. Portanto, tudo está aberto a ajustes pessoais, desde que as ideias centrais sejam mantidas intactas. O repositório vinculado é um fork do projeto original que trouxe essa ideia de design de arquitetura para mim. Sinta-se à vontade para conferir o projeto original também, pois ele reflete outras melhorias.

O diretório webminer é estruturado nas camadas básicas:

entities
use_cases
interfaces_adapters
external_interfaces

Estrutura do diretório webminer

Deve refletir a abordagem básica para o padrão de projeto.

Começando em entities, você pode ver que o modelo central deste projeto é o arxiv_document
A próxima pasta, use_cases, mostra nosso caso de uso – especificamente, requisitar a página arxiv
Depois disso, passamos pela pasta interface_adapters que providencia adaptadores para processos de requisição em uma aplicação REST ou para serialização
A última camada é a external_interfaces. Aqui é onde usamos o servidor flask para implementar a funcionalidade REST

Todas essas camadas dependem das camadas centrais, mas não o contrário.

Uma observação importante: isso não está implementado de modo totalmente correto no repositório.

Por quê? Porque os casos de uso são realmente diferentes. Na realidade, o principal caso de uso é fornecer os dados estruturados. Outro caso de uso é obter os dados da página arxiv.

Você notou esse erro na arquitetura? Se notou, parabéns! Você não apenas veio a este artigo com bastante curiosidade, mas, provavelmente, entendeu os princípios bem o suficiente para construir seu próprio caso e aplicar os conceitos na realidade!

Você concorda? Se não, por quê? Obrigado pela leitura do meu artigo!

Recursos

Aqui estão alguns artigos que considerei úteis para entender o conceito de "arquitetura limpa" (textos em inglês):

Daniel Deutsch é mestrando em direito comercial, trabalha como engenheiro de software e é organizador de eventos relacionados à tecnologia em Viena. Seus esforços atuais de aprendizado pessoal se concentram em aprendizagem de máquina.

Siga o autor em suas redes sociais:

Design para a Web - freeCodeCamp.org