Por Rodrigo Werlang*
Construir um software que tenha atributos de qualidade que aumentem seu reuso e garantam uma evolução e manutenção simplificada sempre foi um desafio técnico para muitas equipes de desenvolvimento de aplicações. Principalmente quando um produto nasce em um ambiente de startup, onde tudo precisa ser pensado para atingir objetivos imediatos e, à medida em que o negócio cresce, os produtos crescem e amadurecem também.
Com o advento de arquiteturas baseadas em microsserviços, definir uma arquitetura robusta e sustentável a longo prazo passou a ser ainda mais complexo. Isso por envolver muitos aspectos de comunicação, resiliência e outros temas comuns em sistemas distribuídos. A etapa de design e arquitetura de software passou a ser fundamental, para que princípios, patterns, tecnologias, atributos de qualidade funcional e não funcional sejam todos estabelecidos com o foco de se criar uma arquitetura que sobreviva às mudanças naturais que serão exigidas. Essas alterações podem existir por necessidades de negócio ou pelo surgimento de novas tecnologias, que é onde a aplicação da filosofia de Clean Architecture usando design patterns começa a fazer a diferença.
Com este enfoque é preciso entender que a arquitetura de um produto de software pode ser classificada de forma distinta dependendo do ângulo em que é analisada. Como, por exemplo, a arquitetura de deploy, ou então a arquitetura lógica, sendo que ambas ainda podem ter vários níveis diferentes de abstração. O ponto de vista em foco aqui será o da visão lógica da arquitetura de um microsserviço em particular. Clean Architecture pode ser entendida como uma filosofia de design de software que separa elementos do design em camadas em forma de anel, onde as dependências somente podem vir dos níveis externos para dentro. Este modelo de arquitetura conceitual produz sistemas que são: independentes de framework, fáceis de testar, independentes de UI (user interface) e independentes de banco de dados.
Ao aplicar clean architecture, cada camada no projeto de software possui uma responsabilidade bem definida, seguindo a regra do primeiro princípio do SOLID (SRP – Single Resonsability Principle; OCP – Open/Closed Principle; LSP – Liskov Substitution Principle; ISP – Interface Segregation Principle; DIP – Dependency Inversion Principle), que é o Single Responsability Principle. A força deste modelo de arquitetura está no fato de ter o domain core, ou a camada de negócios, como centro da arquitetura, o que está totalmente alinhado com o conceito de DDD (Domain Driven Design), muito empregado para definição do contexto e fronteiras de responsabilidade de cada micro serviço.
Clean Arquitecture é um modelo de design de software robusto e provado pela comunidade para criar software que é flexível o suficiente para suportar evoluções e manutenções ao longo do tempo, porque emprega muitos dos princípios modernos de orientação a objetos e permite criar sistemas com baixa dependência entre as camadas e componentes.
Independentemente do modelo de arquitetura escolhido para o design lógico do seu projeto de software, o mais importante é que se leve em consideração que cada camada tenha baixo acoplamento e alta coesão, que as classes sejam organizadas de forma a terem uma única responsabilidade e que, dentre outras coisas, seja fácil adicionar testes sem a necessidade da criação de ambientes complexos e que requeiram um alto esforço para serem implementados.
*Rodrigo Werlang, CTO e Head of Software Engineering Paradigma Business Solutions
Aviso: A opinião apresentada neste artigo é de responsabilidade de seu autor e não da ABES – Associação Brasileira das Empresas de Software
PT 
EN 
