O arquiteto de software que decora padrões e o que entende os princípios por trás deles entregam resultados completamente diferentes. A diferença entre os dois é a mesma que separa o técnico de futebol que copia formação do que entende o jogo. E essa diferença tem nome: pensamento por primeiros princípios.
O técnico que copia e o técnico que entende
No futebol, existe um tipo de técnico que vê o 4-3-3 do Guardiola funcionando no Manchester City e resolve aplicar a mesma formação no time dele. Escala os jogadores nas posições, desenha o campo no quadro branco e espera que o resultado apareça. Quando não funciona (e quase nunca funciona), a culpa é dos jogadores, do gramado, do calendário. Nunca da decisão.
O outro tipo de técnico entende por que o 4-3-3 funciona naquele contexto. Entende que o Guardiola tem laterais que jogam como meias, um volante que recua como zagueiro, e atacantes que trocam de posição constantemente. A formação é consequência de um modelo de jogo, não o modelo de jogo em si. E quando esse técnico vai montar o dele, ele parte do elenco que tem, do campeonato que disputa, das características dos jogadores. E chega numa formação que faz sentido para aquele contexto.
A arquitetura de software funciona exatamente assim.
Primeiros princípios: o mínimo necessário
Primeiros princípios é um modelo mental. A ideia é simples: decompor um problema até chegar nas verdades fundamentais e reconstruir o raciocínio a partir delas. Sem herdar premissas, sem carregar suposições de contextos que não são seus.
A maioria das pessoas raciocina por analogia. “A Netflix usa microservices e funciona bem, então vamos usar microservices”. Isso é analogia pura. Raciocinar por primeiros princípios seria: quais são os requisitos reais do meu sistema? Qual o tamanho do meu time? Qual a maturidade operacional da minha organização? Quais trade-offs estou disposto a aceitar? E a partir dessas respostas, chegar na arquitetura.
Elon Musk fez isso na SpaceX. O mercado dizia que um foguete custava 65 milhões de dólares. Em vez de aceitar, ele decompôs o foguete em matérias-primas e descobriu que o custo dos materiais representava cerca de 2% do preço final. O restante era ineficiência acumulada e premissas que ninguém questionava. O primeiro princípio não era “foguetes são caros”. Era “foguetes são feitos de materiais que custam X, e tudo além disso é decisão de engenharia”.
Imagem gerada pelo Nano Banana Pro
O arquiteto que aplica padrões
Existe um perfil de arquiteto que eu encontro em quase todo projeto: o que coleciona padrões como figurinhas. Sabe o nome de todos, desenha os diagramas, cita os livros certos nos fóruns certos. Mas na hora de justificar por que escolheu determinada abordagem, a resposta é alguma variação de “é o que o mercado usa” ou “vi num case da empresa X”.
Esse é o arquiteto que raciocina por analogia. Pega uma solução que funcionou em outro contexto e transplanta para o seu, sem decompor o problema. É o técnico que copia a formação do Guardiola sem ter o elenco do Guardiola.
O resultado é previsível: microservices onde um monolito resolveria, event-driven architecture onde uma chamada síncrona bastava, Kubernetes para rodar duas instâncias de uma API. Complexidade acidental que nasceu não de um requisito real, mas de uma decisão baseada em referência errada.
Mark Richards e Neal Ford, no Fundamentos de Arquitetura de Software, são categóricos num ponto que deveria ser tatuado na parede de todo time de engenharia: arquitetura é sobre trade-offs. Toda decisão arquitetural tem um custo. O trabalho do arquiteto é entender esse custo antes de tomar a decisão, não depois, quando o sistema já está em produção e o time inteiro está pagando a conta de uma escolha que ninguém questionou.
Na minha experiência, a maioria dos problemas arquiteturais que encontro em projetos não vem de limitações técnicas. Vem de decisões tomadas por analogia. Alguém leu um post, assistiu uma talk, viu um diagrama bonito num slide. E adotou sem decompor se aquilo fazia sentido para o contexto real. O técnico copiou a formação.
O arquiteto que pensa por primeiros princípios
O arquiteto que pensa por primeiros princípios faz o caminho inverso. Em vez de começar pela solução, começa pelo problema. Decompõe os requisitos até chegar nas restrições reais do sistema: performance, disponibilidade, consistência, custo operacional, tamanho do time, prazo. E a partir dessas restrições, constrói a arquitetura.
Quando alguém sugere “vamos usar CQRS”, a primeira reação dele não é avaliar se é um bom padrão. É perguntar: temos um volume de leitura significativamente diferente do volume de escrita? O modelo de leitura precisa ser diferente do modelo de escrita? A complexidade adicional se justifica pelo ganho real que vamos ter? Se a resposta for não, CQRS é over-engineering, independente de quantas empresas grandes usam. Se for sim, aí faz sentido. E faz sentido porque o raciocínio partiu do problema, não do padrão.
Richards e Ford insistem nesse ponto em Arquitetura de Software: As Partes Difíceis: as decisões mais importantes em arquitetura são justamente as que envolvem trade-offs entre características arquiteturais concorrentes. Não existe bala de prata. Cada escolha favorece alguma coisa e sacrifica outra. O arquiteto que pensa por primeiros princípios sabe exatamente o que está sacrificando e por quê. O que aplica padrões muitas vezes nem sabe que está sacrificando alguma coisa.
Particularmente falando, te garanto que a diferença é visível nas reuniões de design review. O arquiteto que partiu de primeiros princípios consegue defender cada decisão com uma cadeia lógica que vai do requisito ao padrão. O que copiou referência empaca quando alguém pergunta “e se a gente não precisar disso?”.
Na prática: três perguntas antes de qualquer decisão
Pensar por primeiros princípios não é exercício filosófico. É uma prática que se desenvolve com perguntas deliberadas. Antes de adotar qualquer padrão ou tecnologia, três perguntas cortam a maioria das decisões ruins:
Qual problema estou resolvendo? Não qual problema o padrão resolve no geral, mas qual problema concreto existe no meu sistema, com meus requisitos, com meu time. Se você não consegue articular o problema com clareza, não está pronto para escolher a solução. É como o técnico que não sabe explicar por que está jogando com três zagueiros, provavelmente não deveria estar jogando com três zagueiros.
Quais são os trade-offs? Nada é de graça. Microservices compram independência de deploy e pagam com complexidade operacional. Com event-driven architecture, você ganha desacoplamento, mas quando um evento se perde no meio de cinco serviços, boa sorte debugando. Se você não sabe o que está pagando, está tomando a decisão no escuro.
Isso funciona para o meu contexto? O case de uma big tech com milhares de engenheiros e budget praticamente ilimitado não se aplica a uma startup de 15 pessoas. Parece óbvio, mas a quantidade de projetos que adotam arquiteturas de escala planetária para servir centenas de requests por minuto é assustadora. Um técnico do Novorizontino não tem o elenco do Real Madrid, e não adianta jogar como se tivesse.
Imagem gerada pelo Nano Banana Pro
Agora, um aviso honesto: primeiros princípios não é para toda decisão. Se você precisa escolher entre dois frameworks de logging, não precisa decompor o problema até a termodinâmica. Existe um risco real de analysis paralysis, ficar desconstruindo indefinidamente quando a decisão tem impacto baixo e é facilmente reversível. O ponto é saber quando a decisão merece essa decomposição e quando basta uma escolha pragmática. Na grande maioria dos casos, o esforço se justifica para decisões estruturais, aquelas que são caras de reverter e que vão definir o caminho do sistema por meses ou anos.
De volta ao campo
O Guardiola não inventou o 4-3-3. Mas ele entende o jogo num nível que permite adaptar qualquer formação ao contexto. No Barcelona, com Messi, Xavi e Iniesta, criou o tiki-taka que revolucionou o futebol. No Bayern, adaptou o estilo ao futebol alemão, mais vertical, mais físico. No Manchester City, montou outro time completamente diferente e seguiu ganhando. Porque o princípio dele nunca foi a formação. O princípio é o modelo de jogo: posse de bola, superioridade numérica, pressão na saída. A formação é só a implementação do momento.
Na arquitetura de software, o princípio não é o padrão. O princípio é o conjunto de requisitos, restrições e trade-offs do seu sistema. O padrão é a implementação. E implementações mudam. Aliás, devem mudar quando o contexto muda.
O arquiteto que entende isso não fica refém de uma tecnologia ou de um hype cycle. Ele resolve problemas. E quando o contexto muda, e sempre muda, ele adapta, porque o raciocínio dele parte dos fundamentos, não das referências.
Se você quer desenvolver isso, recomendo um exercício concreto: pegue a próxima decisão arquitetural que precisar tomar e, antes de pesquisar qual padrão usar, escreva num documento as restrições reais do seu sistema. O que precisa escalar? O que precisa ser consistente? Onde o time tem maturidade e onde não tem? Só depois de ter essas respostas, vá atrás do padrão. Te garanto que a decisão vai ser diferente. E melhor.
Pare de copiar formação. Entenda o jogo.