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.
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
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 é oarxiv_document - A próxima pasta,
use_cases, mostra nosso caso de uso – especificamente, requisitar a páginaarxiv - Depois disso, passamos pela pasta
interface_adaptersque 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 servidorflaskpara 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):
- https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
- https://www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/
- https://github.com/mattia-battiston/clean-architecture-example
- https://medium.com/@tiagoflores_23976/how-choose-the-appropriate-ios-architecture-mvc-mvp-mvvm-viper-or-clean-architecture-2d1e9b87d48
- https://de.slideshare.net/HimanshuDudhat1/mvp-clean-architecture
- https://softwareengineering.stackexchange.com/questions/336677/what-is-the-difference-between-mvp-and-clean-architecture
- https://engineering.21buttons.com/clean-architecture-in-django-d326a4ab86a9
- https://gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b
- https://medium.freecodecamp.org/how-to-write-robust-apps-consistently-with-the-clean-architecture-9bdca93e17b
- https://marconijr.com/posts/clean-architecture-practice/
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: