#Mosiensina: clean architecture
Constantemente somos surpreendidos por um novo termo, filosofia e princípio que tem por objetivo tornar o desenvolvimento de software mais eficientes. Dessa vez, vamos aprender sobre a Clean Architecture, uma filosofia de design de softwares que não é novidade, mas, se você ainda não a adota no seu dia a dia, continue nesse artigo e conheça mais sobre essa estrutura.
Afinal, entender e estudar as arquiteturas de software é essencial para todos os desenvolvedores, independente da senioridade e do tamanho da equipe. Isso porque quando é tomada uma decisão inteligente na escolha da arquitetura aplicada nos desenvolvimentos, é possível evitar um colapso no futuro e garantir que o software a ser construído seja mais robusto, flexível e facilmente replicável.
Entenda mais sobre como surgiu a clean architecture e como ela pode beneficiar você e a sua carreira.
Como surgiu e o que é a clean architecture?
A Clean Architecture foi criada por Robert C. Martin, promovida em seu livro Clean Architecture: A Craftsman’s Guide to Software Structure e em seu blog conhecido como Uncle Bob.
Essa é uma filosofia e metodologia de design de software que reúne princípios organizadores e busca oferecer aos desenvolvedores um raciocínio ao organizar o código, agrupando a lógica de negócio, mas mantendo separado o mecanismo de entrega.
Isso permite a implementação de novos requisitos para a evolução e manutenção do sistema com maior facilidade. Quando se fala em Clean Architecture temos algumas características e vantagens:
- Independente da interface do usuário (UI) — a interface do usuário pode mudar facilmente, sem alterar o restante do sistema.
- Independente de banco de dados — mude o seu banco de dados, escolhendo entre Oracle, Mongo, SQL Server, BigTable, CouchDB ou qualquer outro. As regras de negócios não estão vinculadas ao banco de dados.
- Independente de qualquer agente externo — as regras do seu negócio não interagem com nada do mundo exterior, como frameworks e ferramentas. São totalmente independentes.
- É testável — as regras de negócios podem ser testadas sem a interface do usuário, banco de dados, servidor ou qualquer outro elemento externo.
O diagrama da arquitetura limpa
No diagrama, as “Entities” (entidades ou regras de negócio da empresa, com domínios simples), são o núcleo interno. Elas são rodeadas dos “Use Cases”, ou regras de negócio do aplicativo, são os presenters, controllers ou gateways. Há, ainda, as interfaces externas, como DB, UI ou web, chamadas de public shell or public surface ou interface.
Nota-se que todas as estruturas e drivers estão nas camadas mais externas. Nesse diagrama, as dependências se movem do interior para o exterior, ou seja, do número para a superfície externa ou pública. Não há a dependência entre as entidades internas e casos de uso, o que faz com que elas sejam menos propensas a mudanças, já que cada camada tem dependência de outra camada próxima a ela.
Portanto, as camadas externas são mais propensas a se adaptar através de tecnologias e, consequentemente, a arquitetura da solução tem menos impacto na lógica dos aplicativos principais. A divisão do sistema em camadas é uma forma de construir uma boa estrutura, com baixo acoplamento e alta coesão.
Entenda o que cada camada deve conter:
Entities (entidades)
Onde é alocada a lógica de negócio e as regras de alto nível. Essa é a camada que poderá ser utilizada por todas as outras mais externas, e por isso possui regras gerais do software.
Use Cases (casos de uso)
Neste nível, aplica-se às regras de negócio para cada caso. É uma camada de lógica, em que se descreve a lógica principal do negócio ou do aplicativo e usa uma camada de domínio, criando resultados que não sabemos como serão apresentados. Com base nos serviços, mantemos a lógica de negócios independente da interface do usuário ou banco de dados e o uso de bibliotecas é feito apenas como ferramenta.
Interface Adapters
A camada de adaptadores de interface tem a função de atuar como um comunicador para converter dados no formato desejado para armazenar em fonte externa, como banco de dados, sistemas de arquivos, além de converter os dados para a lógica do negócio. Ou seja, sua principal função é converter as informações vindas das camadas internas (entidades + casos de uso) para reconhecer elementos que pertencem ao próximo nível.
Frameworks and Drivers (interfaces externas)
Camada mais externa que muda com frequência a partir de tecnologias, base de dados atualizadas e novas estruturas Web front-end. É aqui onde apresenta-se os dados para a interface do usuário ou banco de dados.
Quando e como aplicar a arquitetura limpa em um projeto de desenvolvimento?
Para se tomar uma boa decisão ao escolher a arquitetura de um software, é preciso levar em conta se a escolha potencializa e facilita o trabalho a ser realizado. É fundamental que seja feita uma análise da real necessidade de investimento nesse tipo de infraestrutura.
De forma geral, a clean architecture se adere melhor na construção de aplicações mais complexas, que têm capacidade de suportar processos de negócios mais relevantes, com garantia de manutenção a longo prazo, mas para aplicações menores e mais simples, não há a necessidade e investir nesse tipo de tecnologia pode ser desnecessário.
Exemplo: não vale a pena investir na clean architecture na construção de um blog simples, que possui apenas funcionalidades CRUD em seus serviços.
Se bem implementado, a arquitetura limpa na construção de códigos oferece flexibilidade, pois, por ser uma arquitetura incremental, podemos tomar decisões temporais sobre quais incrementos nosso código precisa.
Deu para entender a relevância desse tipo de arquitetura para o desenvolvimento de software, não é? E agora, que tal dar uma olhada em nosso banco de talentos para ver se alguma vaga tem o seu perfil?
Clique aqui e acesse nossa página de carreiras. Esperamos você lá!
