No mundo atual, praticamente tudo o que acontece no cotidiano das pessoas, passa por algum tipo de sistema computacional. Desde simples tarefas do dia a dia, como assistir filmes nos muitos serviços de streaming disponíveis ou pedir refeições pelo smartphone, até o desenvolvimento de foguetes espaciais. A rotina de pessoas e empresas está literalmente conectada aos softwares.
É importante que a produção e manutenção de softwares seja capaz de atender à crescente demanda, focando em seu crescimento e na otimização desses sistemas, estabelecendo custos adequados e sem prejudicar seu desenvolvimento.
Nesse sentido, a engenharia de software é diretamente responsável por diversos aspectos durante o processo de criação de sistemas computacionais e algumas regras de boas práticas podem fazer diferença na produtividade do projeto.
Profissionais que dominam e praticam essas regras em sua rotina têm maior facilidade na execução de tarefas como especificação, desenvolvimento, validação e evolução de um programa.
Sugerido por Robert Martin, o padrão de arquitetura limpa (Clean Architecture) tem como função promover a implementação de softwares, favorecendo a reutilização de código, coesão, independência de tecnologia e testabilidade.
Neste artigo, você vai compreender o conceito que envolve a arquitetura limpa e de que maneira ela pode ser utilizada.
Tenha uma ótima leitura!
O conceito de arquitetura de software
Esse pode ser um conceito bastante amplo, pois é de fato mais subjetivo do que objetivo. E as diferentes interpretações e opiniões dependem bastante da experiência de cada desenvolvedor. Todos os inúmeros pontos de vista podem muitas vezes estar corretos e fica difícil sacramentar uma única definição. Mesmo assim, é possível termos algumas noções.
Basicamente, a arquitetura de software deve garantir a unificação entre as partes integrantes de um programa e envolve todas as decisões estruturais que formam esse sistema: controle, protocolos de comunicação, acesso aos dados e sua sincronização, definições de funcionalidades, distribuição física dos componentes e como será sua escalabilidade e desempenho.
Arquitetura de software é o conceito que trata a relação entre o mapeamento de todos os componentes que integram um sistema com as singularidades que devem ser abordadas no momento de implementar estes elementos em forma de códigos.
É o modelo que torna possível um melhor entendimento e a análise mais profunda no desenvolvimento de um software, evitando possíveis erros futuros.
Por que é importante estudar arquitetura de software
Imagine todo o processo de desenvolvimento de um sistema, com todos os desafios envolvidos, para descobrir no futuro que ele está engessado e não tolera alterações.
Isso pode criar obstáculos na implementação de novos requisitos que deveriam agregar valor ao programa original, impedindo, então, sua evolução e até mesmo uma maior praticidade em sua manutenção.
Independentemente do tamanho do projeto ou da equipe de desenvolvedores, um bom entendimento da arquitetura de software pode aumentar a escalabilidade e flexibilidade de um sistema e deixá-lo menos suscetível a colapsos.
Entre as diferentes opções de arquitetura, uma de grande destaque é a arquitetura limpa (ou clean architecture, em inglês).
O conceito de arquitetura limpa
Deve ficar muito claro na consciência de todos os desenvolvedores de programas, principalmente dos que ainda estão na fase de aprendizado ou aqueles que começaram recentemente suas carreiras, que utilizar um código sujo pode ser arriscado e apresentar alguns problemas no futuro.
Vamos fazer uma analogia entre a construção de um software e a de uma casa. Imagine todo o processo de desenvolvimento da residência, desde o projeto até a entrega das chaves.
Ao projetar e construir uma casa, bons arquitetos e engenheiros devem confluir suas ideias, sempre respeitando regras específicas, para que, após a entrega do imóvel, qualquer tipo de alteração possa ser realizada da maneira mais prática possível.
Imagine que algum tempo depois do imóvel pronto, o proprietário resolve fazer alguma alteração física da residência, como, por exemplo, ampliar um quarto, acrescentar um novo banheiro e fazer uma nova janela.
Dependendo de como a casa foi concebida na mesa do arquiteto, uma alteração pode se tornar mais dispendiosa, demorar mais tempo para ser concluída, ou até mesmo impossível.
Assim como o planejamento de uma casa deve ser responsável e seu produto final precisa ter flexibilidade para alterações ou ampliações, a criação de um software também deve favorecer a qualidade do código.
Vale lembrar ainda que, assim como um arquiteto de uma casa, o desenvolvedor do programa é o responsável pela entrega do produto e provavelmente em possíveis upgrades futuros.
Estabelecer uma arquitetura limpa pode facilitar seu próprio trabalho a médio ou longo prazo.
O que é arquitetura limpa
Robert Cecil Martin (Uncle Bob ou Tio Bob, como é mais conhecido) foi quem propôs a arquitetura limpa, em 2021. Seu objetivo era padronizar e organizar o código que está sendo desenvolvido e dessa maneira favorecer a sua reusabilidade, ou seja, capacitar um software para ser usado em novas aplicações.
Tio Bob afirma que a aplicação de boas práticas de engenharia antes, durante e após um projeto é fundamental. A razão disso é na verdade bastante simples: é mais fácil alterar um programa que não funciona, porém está bem dividido e arquitetado, em vez de um sistema que, embora funcione, está engessado.
É possível ter ganhos de rendimento e produtividade durante o processo de desenvolvimento de um novo sistema usando menos esforço, por meio de técnicas, como TDD (Test Driven Development, em português, desenvolvimento guiado por testes). Que é quando um código pode ser testado e verificado em diversas situações, de maneira automatizada.
Entretanto, é importante que o desenvolvedor/arquiteto defenda uma boa engenharia, os bons princípios e os padrões de qualidade. Lembre-se de que a arquitetura deve favorecer a reusabilidade deste código.
Existem outros modelos para montar a arquitetura de um projeto em relação à estrutura do código: organização do código, componentes, as bibliotecas e frameworks.
Não confunda os modelos de arquitetura
Quando se aprende sobre a arquitetura limpa, em algum momento você vai encontrar modelos semelhantes de arquitetura, que também têm como princípio a criação de diversas camadas para isolar o core da aplicação.
Esse princípio é chamado de Separação de Responsabilidades (em inglês, Separation of Concerns – SoC). Veja agora alguns modelos que com certeza você irá encontrar:
Arquitetura Hexagonal (Hexagonal Architecture)
Também conhecida como Ports and Adapters, a arquitetura hexagonal foi criada por Alistair Cockburn e muitas vezes acaba confundindo desenvolvedores com a arquitetura limpa. Isso acontece devido à semelhança com a Clean Architecture e por também funcionar como uma arquitetura Domain-Centric (quando o modelo de estrutura entende que o domínio é o motivo pelo qual o programa existe).
Arquitetura Cebola (Onion Architecture)
O termo Onion Architecture (Arquitetura Cebola) foi criado por Jeffrey Palermo, em 2008. Esse modelo oferece uma alternativa robusta para desenvolver aplicativos para uma melhor testabilidade, manutenção e confiabilidade nas infraestruturas como bancos de dados e serviços.
Na arquitetura tradicional, a camada da interface do usuário interage com a lógica de negócios, que por sua vez conversa com a camada de dados e todas as camadas acabam sendo misturadas e, por isso, dependem muito uma da outra.
Nas arquiteturas de três e n-camadas, nenhuma delas é independente. O que leva à necessidade de uma separação de responsabilidades. Estes sistemas podem ser complexos de entender e manter. A desvantagem dessa arquitetura tradicional é o acoplamento desnecessário.
A arquitetura em cebola resolveu esse problema definindo camadas a partir do núcleo para a infraestrutura.
Separação (ou divisão) de Responsabilidade
No que se refere à arquitetura limpa, existe uma divisão bem definida das camadas. Sua estrutura tem independência de framework, pois suas camadas internas que possuem as regras de negócio não precisam depender das bibliotecas de terceiros.
Permite ao desenvolvedor usar o framework como ferramenta, sem a necessidade de adaptar o sistema para que ele aceite especificações das tecnologias a serem utilizadas.
A arquitetura limpa tem como características a testabilidade, independência da UI e do banco de dados ou de qualquer agente externo (as regras de negócio não devem saber nada sobre as interfaces do mundo externo).
Talvez você esteja se perguntando agora como camadas tão independentes podem realizar alguma comunicação entre elas. Essa questão é solucionada com o Princípio de Inversão de Dependência.
Uncle Bob propôs a ideia de organizar as interfaces e relacionamentos de herança, deixando as dependências de código fonte opostas ao fluxo de controle em pontos assertivos.
Quando um caso de uso tentar uma comunicação com o apresentador, esse contato não pode ser direto, pois estaria violando a Regra da Dependência.
Portanto, o caso de uso vai utilizar a interface do círculo interno e o apresentador no círculo exterior é quem faz a implementação.
Entidades e casos de uso da arquitetura limpa
No centro da arquitetura encontram-se as classes responsáveis pelas regras do negócio. São dois tipos: entidades e casos de uso.
Entidades
Essas classes são usadas com frequência em muitos sistemas de organizações e entidades. Um exemplo é o de uma universidade, que conta com sistemas acadêmico, financeiro, extensão, por exemplo. Estes sistemas consequentemente vão lidar com classes como alunos, professores, cursos, departamentos.
Estas classes são chamadas de entidades, que além de dados são capazes de implementar regras de negócios genéricas. Um exemplo disso é em uma situação na qual a universidade determina que um professor pertence a um determinado departamento.
Casos de uso
Os casos de uso se encarregam de regras de negócios específicas do sistema. Ainda usando o exemplo da universidade, imagine o mesmo sistema acadêmico, que pode ter uma classe, DIÁRIO DE CLASSE, encarregada de armazenar a lista de objetivos do tipo ALUNOS matriculados em uma determinada DISCIPLINA.
A regra de negócio vai definir que um aluno só poderá ser incluído em um diário de classe, se ele estiver inserido dentro dos pré-requisitos de sua disciplina.
Adaptadores e frameworks externos
Adaptadores
Em uma terceira camada, estão as classes e interfaces conhecidas como Adaptadores. Sua função é intermediar a relação entre os sistemas externos da arquitetura (camada externa) e as camadas centrais (casos de uso e entidades).
Temos como exemplo, um sistema que utiliza uma API Rest. São as classes adaptadoras, as responsáveis pela implementação dos endpoints Rest da API.
Isso significa que elas recebem as requisições e devem encaminhá-las para os respectivos casos de uso.
Frameworks
Na camada mais externa, funcionam as classes de bibliotecas, frameworks e demais sistemas externos. Essa camada é onde ficam os sistemas responsáveis pela persistência em bancos de dados, envios de e-mails, comunicação com provedores de pagamentos e determinados hardwares, construção de interfaces com usuários.
O que mais você precisa saber sobre arquitetura limpa
É importante saber que, no modelo de arquitetura limpa, as classes de uma determinada camada não devem conhecer as camadas mais externas. Uncle Bob afirma que “o nome de um elemento declarado em uma camada externa não deve ser mencionado pelo código de uma camada interna. Isso inclui funções, classes, variáveis e qualquer outro elemento de código”.
Regra de dependência
A Regra de Dependência vai garantir que tanto entidades quanto os casos de uso sejam classes limpas de qualquer tecnologia ou serviço externo ao programa.
Dessa maneira, em uma arquitetura limpa as camadas centrais têm maior estabilidade, sendo menos suscetíveis a alterações do que as camadas exteriores.
Invertendo o Fluxo de Controle
Na arquitetura limpa, os fluxos de controle de fora para dentro trabalham naturalmente. Pois eles vão seguir o mesmo sentido estabelecido na regra de dependência.
Quando adotar a arquitetura limpa
Ao ser aplicado, o modelo ajuda na manutenção e na evolução da aplicação, sem a necessidade de despender muitos recursos, físicos e de tempo.
A arquitetura limpa têm melhores resultados quando for usada na implementação de sistemas com níveis maiores de complexidade e que tenham a capacidade de suportar processos de negócios relevantes.
Verifique se é uma vantagem construir um software com flexibilidade e que tenha seus processos independentes e os componentes desacoplados.
Ou então quando a necessidade de realizar manutenções frequentes, durante períodos maiores, for mais comum.
Se você gostou e quer entender ainda mais sobre arquitetura de software e tecnologia, continue acompanhando o nosso blog.
