Como a Clean Architecture é um tema que leva algumas considerações importantes sobre Arquitetura de Software e Design de Software, iremos observar algumas dessas relações e diferenças para entendermos mais a fundo esse padrão de desenvolvimento.
Arquitetura de Software
Com base em livros e artigos da comunidade, a Arquitetura de Software é definida como um meio de estruturar projetos para atenderem os requisitos de qualidade do negócio, mas de uma forma que faça com que os software se mantenham sustentáveis ao longo do tempo. Afinal de contas, quem nunca esteve num projeto que seria um fardo para quem precisasse mantê-lo no futuro, ou mesmo quando nos deparamos com projetos deixados por outros desenvolvedores, que apresentam erros quando nós fazemos algumas alterações?
Mas esse problema não é necessariamente do desenvolvedor, já que nós sempre tentamos resolver o problema da melhor forma possível, principalmente quando estamos com um tempo limitado e trabalhando sob muita pressão. É difícil julgar já que acontece com muita frequência, mas a melhor forma de lidar com isso é pensar em tomar as melhores decisões para fazer com que o software seja durável. Geralmente não acontece pelas más decisões ou erros que nós cometemos, mas o problema é quando esse tipo de coisa se acumula ao longo do tempo a ponto de fazer com que os nossos projetos fiquem insustentáveis.
Como as empresas pagam muito caro pelos softwares e o retorno desse investimento não é imediato, muitas vezes esses softwares apresentam falhas tão grandes a ponto de obrigar essas empresas a começarem um novo projeto. Então, o objetivo da Arquitetura de Software é sobre como tomar decisões relevantes, que ajudem no desenvolvimento e na sustentabilidade do projeto, facilitando outras alterações que podem ser feitas durante a evolução do software.
É como construir a fundação de um prédio, sabendo que depois de construí-la não é mais possível refazê-la sem derrubar todo o prédio. E, se você faz uma fundação ruim, você ainda deve mantê-la até o momento em que o prédio estiver pronto. E quanto mais tempo você utiliza preparando um software, menos tempo você perde com a sua manutenção. Mas quanto menos tempo você gasta nessa estruturação, mais tempo no futuro você irá perder fazendo reparos. É uma regra muito clara.
Design de Software
Considerando as diferenças entre design e arquitetura, mesmo que algumas pessoas pensem que são áreas semelhantes, esses padrões são realmente diferentes. A arquitetura, de fato, abrange o design; mas o design nem sempre se relaciona à arquitetura.
O objetivo do Design de Software é organizar e utilizar boas práticas de engenharia durante o desenvolvimento do software, cuidando da sua projeção da melhor forma possível para trabalharmos nele. Quando pensamos em Solid, nos padrões e regras de design, isso se refere a como nós iremos desenvolver o software. Mas, quando nós pensamos em qual sistema de logs utilizar ou nas abstrações que devemos fazer, etc, essas decisões ainda cabem ao designer.
Porém, quando nós escolhemos a ferramenta de logs que nós vamos utilizar, seja Elastic ou Papertrail, por exemplo, essa é uma decisão arquitetural que vai além do código. E nesse contexto a escolha da ferramenta de log é uma decisão arquitetural, mas que também envolve Design de Software no momento em que implementamos o log.
Então o Design de Software é sobre quando pensamos exclusivamente em como trabalhar e organizar a aplicação, tomando as melhores decisões e com um alto desacoplamento.
Clean Architecture
No livro do Uncle Bob (Robert Martin) sobre Clean Architecture, nós vemos que a arquitetura envolve completamente o panorama do software como um todo, incluindo a nossa decisão de instalar um interruptor na parede e em como nós pensamos em organizar esse detalhe. Como podem haver muitas decisões ruins sobre como colocar um interruptor na parede, não necessariamente por responsabilidade do arquiteto, mas do pedreiro que vai fazer isso; boa parte do que nós aprendemos sobre Clean Architecture considera esse tipo de trabalho.
A arquitetura normalmente não chega a nível de código para cuidar dessas definições, pois se chegarmos a esse ponto provavelmente as decisões serão tomadas porque o software vai impactar outros softwares, mas não ele mesmo. E, quando o software causa impacto a ele mesmo, há o risco de que ele fique desacoplado e difícil de se manter, sem seguir o Solid ou o uso do design pattern correto. E essas decisões vão caber muito mais ao design e não necessariamente à arquitetura.
Dizer que Clean Architecture não tem relação com Arquitetura de Software é um equívoco, já que de uma forma ou de outra pensar de forma arquitetural em alto nível também nos permite criar uma padronização em todos os softwares em torno do nosso ecossistema. De fato a Clean Architecture tem relação com arquitetura, mas quando nós trabalhamos em camadas, como as camadas de entidade ou de use case, boa parte do que nós vemos nos princípios do Solid, de Dependency Inversion, etc, se referem mais ao design.
Vale lembrar que boa parte da sua rotina como desenvolvedor, incluso o que o seu software contém, é o design. E você pode até discordar disso, mas essas considerações tem base em experiências, justamente como no livro do Uncle Bob, no qual ele passa a ideia sobre Clean Architecture detalhando as suas histórias e experiências, sem se apegar muito à definições superficiais. Na sua experiência desenvolvendo softwares o Uncle Bob afirma que frequentemente eles ficavam difíceis de se manter, percebendo que ao invés de tomar decisões importantes no início do projeto, ele poderia deixá-las para depois.
Muitos de nós começamos um software pensando, por exemplo, em qual banco de dados usar, qual RM escolher e como eles vão funcionar, mas é fato que muitas decisões de desenvolvimento podem ser tomadas mais pra frente. O problema é que escolher tomar decisões que não são importantes naquele momento pode fazer com que as coisas saiam do controle e excedam algumas barreiras desnecessárias. Decisões sobre framework, bancos de dados, sistema de cache ou qualquer outra coisa desse tipo ainda são válidas e fazem sentido para o seu projeto, mas se você pensar bem o domínio do software é o que mais importa no final das contas.
Separando as complexidades:
Quando nós montamos um software, o nosso objetivo é resolver um problema. Quando você tem um problema como calcular juros, por exemplo, esse é justamente o objetivo principal do seu software. Se o software que você trabalha vai utilizar HTTP, gRPC, Kafka, MySQL ou qualquer outro tipo de ferramenta, isso são apenas detalhes externos, sendo que nesse momento você deve separar e organizar o que é mais importante.
Complexidade do Negócio e Complexidade Técnica
Nós podemos até mesmo fazer uma clara separação entre a complexidade do negócio e a complexidade técnica acidental. A complexidade do negócio é a razão pela qual você faz o software, seja qual for o objetivo final dele, e é nisso que você deve pensar para resolver o problema. Mas quando você pensa em API REST, gRPC, PHP ou MySQL, essas são complexidades técnicas e acidentais que nós escolhemos ter, que nós adicionamos para tentar resolver toda a complexidade do negócio. Isso pode parecer óbvio, já que naturalmente nós precisamos de ferramentas, bibliotecas, códigos, frameworks, bancos de dados, abstrações e entre outras coisas para resolver o problema da melhor forma possível. Mas muitas vezes essa é a raiz do problema.
No exemplo do cálculo de juros, se o cliente pede um sistema que cumpra essa função, ao invés de pensarem nisso, há desenvolvedores que começam a misturar a complexidade técnica à complexidade do negócio, atrapalhando o objetivo do software. Em resumo, misturar as complexidades gera um grande ruído e, quando isso acontece, não se consegue resolver nem uma coisa, nem outra. E é muito importante se lembrar disso.
Entenda que a Clean Architecture foi criada com base nas experiências de muitas pessoas que evoluíram ao longo do tempo em cada um desses aspectos. Isso foi trabalhado com muitos princípios, que não necessariamente foram inventados pelo Uncle Bob, já que muitas vezes ele tomou referências de alguém que já tinha feito alguma coisa e evoluiu a sua forma de pensar.
Se você você pesquisar sobre Ports & Adapters (Arquitetura Hexagonal), Onion Architecture ou outro segmento semelhante, você vai perceber que tudo isso é igual à Clean Architecture no ponto que nos estimula a pensar no coração do negócio e deixar as complexidades externas por último.
Então, lembre-se que não basta nos códigos e pastas sem ter uma ideia geral do domínio, que é o coração do software, porque nisso há o risco de misturar as complexidades e criar um software difícil de se adaptar.
Quer saber um pouco mais sobre Clean Arquitecture? Confira esse post.
Se curtiu esse conteúdo e quer aprender como Clean Arquitecture pode transformar seu desenvolvimento, solicite um contato clicando aqui que nós te ajudamos.
