“Aqui a gente usa uma arquitetura que a gente mesmo criou...”
Se você já ouviu (ou falou) isso, provavelmente já está sentindo um leve arrepio no teclado. 😅 E se ainda não ouviu, prepare-se: é questão de tempo até topar com um sistema que mais parece uma ficção científica mal escrita.
Vamos conversar sobre essa mania quase ritualística que muitos times devs têm de criar A Arquitetura Suprema™, única, personalizada, como se o projeto fosse uma startup unicórnio em Marte — quando, na real, é um CRUD de orçamento com autenticação e um botão de exportar pra Excel.
O ego do dev arquiteto (e o custo disso)
No fundo, no fundo, criar uma arquitetura do zero dá aquela sensação boa de poder. É como brincar de Lego: você decide onde vai cada pecinha. Só que, diferente do Lego, aqui o tempo custa caro e o time do futuro vai te xingar em 3 linguagens diferentes.
Arquitetura customizada demais, sem seguir padrões consolidados como DDD, Clean Architecture ou até um MVC bem feito, vira dívida técnica disfarçada de inovação. Você pode até convencer o time de que aquele handler mágico com 5 middlewares e 12 interceptadores é o caminho — mas daqui 6 meses, quando outro dev tentar dar manutenção, vai ser tipo montar um quebra-cabeça com peças de jogos diferentes.
O paradoxo da inovação: nem tudo precisa ser novo
Aqui entra um dos gatilhos mentais mais traiçoeiros do mundo tech: o da curiosidade. O desenvolvedor vê uma arquitetura no Medium, ou assiste uma talk sobre microserviços em Kubernetes, e pronto — quer aplicar isso no sistema de controle de ponto do RH.
Mas inovação sem propósito é só complexidade disfarçada.
Você não ganha pontos por usar 3 filas Kafka, 2 sagas e uma pitada de event sourcing num projeto que tem 50 usuários ativos. Isso não é arquitetura moderna — é overengineering gourmet. E a conta vai chegar. Ah, vai.
"Mas aqui é diferente..."
Todo dev já ouviu (ou disse) isso. É o mantra da customização desenfreada: “nosso caso é especial”. Spoiler: 90% das vezes, não é.
Empresas bem-sucedidas, de todos os tamanhos, adotam padrões. Do iFood ao Nubank, do Magazine Luiza ao seu sistema interno de gestão de planilhas — todos ganham em previsibilidade, reuso e facilidade de onboard.
Quando você foge dos padrões por "excesso de criatividade", está empurrando seu projeto pro isolamento técnico. E sabe o que mora no isolamento? Bugs, burnout e devs com vontade de mudar de time.
Ok, mas e a tal da flexibilidade?
Agora você pode estar pensando: “Então é pra fazer tudo igual sempre?”. Calma, jovem padawan. Flexibilidade é importante, sim. Mas ela precisa nascer de um alicerce sólido — e não de um castelo de areia feito com conceitos que só você entende.
Padrões servem pra você ganhar tempo com o que realmente importa: regras de negócio, performance, experiência do usuário. Não pra você perder semanas discutindo onde vai ficar a camada de orquestração do seu Domain Notification Aggregator (que, sejamos honestos, ninguém além de você entende).
Conclusão: menos show, mais código sustentável
No fim das contas, arquitetura não é palco pra ego. É fundação. E fundação boa é aquela que permite que outras pessoas construam em cima — sem medo, sem dor e sem precisar te ligar no domingo à noite pra entender como fazer um PUT funcionar.
A real maturidade de um time está em saber quando inovar e quando apenas seguir o que já funciona.
E antes de criar o seu próximo “framework próprio com arquitetura que a gente bolou aqui”, dá uma olhada em como o mercado está resolvendo esse problema. Talvez a resposta esteja ali, no bom e velho Clean Architecture com um toque de simplicidade.
Afinal, o que é mais sexy do que um sistema que funciona, é escalável e qualquer dev consegue entender?
Nada. Absolutamente nada. ❤️
"Simplicidade é o último grau de sofisticação."
– Leonardo da Vinci (e todo dev que já limpou a bagunça de um sistema “visionário”)
Quer continuar esse papo? Me conta nos comentários: qual foi a arquitetura mais bizarra que você já viu em produção? 😬
Top comments (0)