A Importância de Entender a Origem dos Conceitos em Arquitetura de Software

Ao longo da minha carreira como desenvolvedor, recrutador e líder de projetos, uma questão sempre chamou minha atenção: a diferença entre seguir um padrão por compreender sua essência ou simplesmente aplicá-lo como uma regra inflexível. Um exemplo clássico disso pode ser observado na adoção da Arquitetura Limpa, popularizada pelo Uncle Bob (Robert C. Martin), especialmente no contexto de casos de uso.

Casos de Uso: Compreensão Essencial e Prática

Minha primeira interação com o conceito de casos de uso aconteceu enquanto eu estudava UML (Unified Modeling Language). Na época, trabalhando com programação estrutural e começando a explorar a orientação a objetos, fiquei fascinado com a ideia de mapear ações do usuário diretamente para funcionalidades do sistema. Era como assistir as interações do mundo real ganharem vida no código.

O conceito básico é simples: um caso de uso representa uma interação significativa. Exemplos incluem registrar devoluções de um livro, realizar o onboarding de um cliente, ou gerenciar reservas em um sistema. No entanto, ao longo do tempo, vi a ideia original se perder em projetos onde o entendimento sobre os casos de uso era superficial. Casos de uso foram transformados em funções genéricas, como “AddBookUseCase”, sem considerar a essência prática que deveria guiá-los.

A Subversão dos Conceitos ao Longo do Tempo

Isso não ocorre apenas com casos de uso. Em muitos projetos, a essência de conceitos fundamentais é desvirtuada pelo uso inadequado ou por um entendimento parcial. Recentemente, vi um exemplo curioso: um desenvolvedor questionava algo sobre UML em um post, sem saber que estava respondendo ao próprio criador da metodologia. Esse tipo de desconexão mostra como a história e os propósitos originais de uma ferramenta ou padrão podem se perder.

https://www.reddit.com/r/MurderedByWords/comments/1676zgq/i_guess_maybe_he_does_know_something_about_uml/?rdt=38576

O impacto disso no dia a dia de projetos é significativo. Quantas vezes vemos sistemas sobrecarregados com camadas e mais camadas de indireção porque alguém insistiu em seguir um padrão sem compreender sua aplicabilidade?

A Reflexão: A Base É Essencial

O grande aprendizado aqui é: compreender a base é essencial para aplicar qualquer padrão ou arquitetura de maneira eficaz. Para isso:

1. Revisite os conceitos fundamentais: Releia livros, estude a origem dos padrões e entenda as motivações que levaram os autores a propor tais ideias.
2. Avalie o contexto: Nem todo padrão se aplica a todos os projetos. Pergunte-se: este padrão agrega valor ao meu sistema no estágio atual de maturidade?
3. Pondere os prós e contras: Camadas adicionais de complexidade valem o benefício que você está tentando alcançar?
4. Respeite o objetivo original: Ao adotar um padrão, tente implementá-lo da maneira mais próxima possível da visão do autor, adaptando-o às suas necessidades apenas com entendimento claro.

Conclusão

O que faz sentido para um projeto em um contexto pode ser completamente inviável em outro. Não existe uma arquitetura perfeita, mas sim uma arquitetura adequada para um momento específico. Como desenvolvedores, líderes ou mesmo aprendizes, nosso objetivo deve ser construir sistemas que sejam eficientes e compreensíveis, em vez de tentar “encaixar” padrões pelo simples fato de serem populares.

Ao refletir sobre isso, concluo que a melhor prática é manter-se curioso, revisitar conceitos básicos e estar sempre aberto a adaptar e aprender. Afinal, tecnologia é um campo de constante evolução, mas os princípios sólidos nunca saem de moda.

Um grande abraço e até logo!