Disclaimer

Este texto foi concebido pela IA Generativa em função da transcrição do episódio do nosso canal, Dev Eficiente. O episódio completo pode ser visto no canal.

Introdução

No desenvolvimento de software, especialmente em ambientes corporativos, as mudanças são inevitáveis. No entanto, na minha visão, o que mais muda não são as tecnologias, mas sim as pessoas.

Uma abordagem maximiza a chance de ganho de flexibilidade de partida, mas pode ser necessária combinar mais técnicas para também maximizar a chance do código de fato facilitar o entendimento.

Você pode se inspirar em arquiteturas como a Clean Architecture ou qualquer outra arquitetura em camadas e continuar utilizando métricas derivadas do CDD (Cognitive-Driven Design) para controlar o entendimento do coração do seu software.

Por exemplo, podem ser definidos limites de complexidades para adapters, casos de uso, entidades etc.

Controlando a Complexidade

Vamos supor que você tenha uma métrica onde cada acoplamento contextual, passagem de função como argumento e branch de código conta um ponto, e o limite é sete. Se ao somar todos os pontos você atingir o limite, é hora de reorganizar a lógica ou quebrar em outra unidade para respeitar o limite.

Também podem ser estabelecidos em função da camada. Na camada de adaptadores, pode-se trabalhar com limites mais restritivos. A ideia ali é que seja de fato muito fina. Já na camada de casos de uso/application service, pode-se trabalhar com um limite um pouco maior, já que ali teremos organização de fluxos de chamadas que podem variar de complexidade em função do requisito.

Indireções e Abstrações

Ao lidar com arquiteturas em camadas você, automaticamente, vai trabalhar com indireções. Você vai criando indireções e generalizando essas indireções conforme necessário. Se você dominar os conceitos básicos de orientação a objetos, modelagem e polimorfismo, conseguirá implementar qualquer tipo de arquitetura em camadas, pois os princípios são os mesmos.

Desacoplando do Framework

Um dos passos importantes é se livrar das dependências diretas com frameworks. Por exemplo, se você tem um repositório acoplado ao Spring, pode criar uma indireção para desacoplar. Isso envolve criar interfaces e métodos que abstraem a lógica do framework, permitindo que o seu caso de uso não dependa diretamente do Spring.

A energia para resistir a influência do framework

Considero que determinados frameworks exercem uma força contínua sobre seu código, aumentando demais o gasto energético de manter tudo desacoplado.

Por exemplo, quando trabalhamos com ORMs, algumas vezes temos que lidar com objetos sendo gerenciados de maneira mágica, gerando acessos não planejados ao banco de dados etc. É possível controlar tudo na unha? Sem dúvida. É fácil o tempo inteiro? Considero que não.

Complexidade Percebida vs. Calculada

A complexidade percebida é diferente da complexidade calculada. Mesmo que um código seja mais complexo de acordo com uma métrica, ele pode ser percebido como menos complexo por alguém que domina a arquitetura utilizada. Portanto, a percepção de complexidade é sempre individual.

Essa percepção individual é a que me faz considerar importante estabelecer uma maneira comum de contabilizar complexidade e também de estabelecer um limite. Você não quer que cada pessoa da sua equipe entregue código que oferece uma experiência de manutenção completamente diferente.

A intenção de uma Arquitetura em Camadas

Arquiteturas em camadas visam proteger o software de mudanças em tecnologias, protocolos e interfaces. Não apenas isso, mas é uma parte da expectativa. A ideia é postergar decisões e se proteger de mudanças externas. Isso é feito criando camadas de indireção que isolam a lógica do software das tecnologias específicas.

A intenção aqui é importante porque, para mim, ela vem antes das técnicas. A intenção te dá liberdade para experimentar ao mesmo tempo que mantém um norte na sua cabeça sobre onde você quer chegar.

Conclusão

A criação de indireções e a abstração das dependências externas são passos fundamentais para alcançar o objetivo proposto por qualquer arquitetura em camada. Embora a complexidade percebida possa variar, a aplicação desses princípios pode te levar a um software que exija menos modificações em função de necessidades de adaptação a tecnologias no futuro.

Nesta conclusão considero importante ressaltar o "pode te levar". Não vai adiantar criar camadas intermediárias se, lá dentro, o código faz menção a códigos HTTP por exemplo. Neste caso, o esforço contínuo de separação pode virar, na verdade, um desperdício de energia.

Vamos falar mais ?

Se você gostou, deixa um comentário aqui. Tem um comentário construtivo? Deixa aqui também, com educação.

Conheça mais sobre a Jornada Dev + Eficiente

A Jornada Dev + Eficiente é um treinamento cujo objetivo é fazer com que você busque as melhores posições como Dev impulsionado pela sua profundidade técnica em Design e Arquitetura de Software.

Trabalhamos quatro grandes áreas:

1. Capacidade técnica em Design e Arquitetura de Software
2. Capacidade de aprendizagem cada vez mais eficaz
3. Capacidade de impactar o meio através do seu conhecimento
4. Grande poder de execução

Para saber mais, acesse em https://deveficiente.com