Por que o mundo simplesmente não funciona como deveria
A gente cresce ouvindo que as coisas vão se encaixar. Que se você seguir o roteiro, vai dar certo. A realidade é bem mais chata que isso.
kono sekai wa fukanzen sugiru e a falta de sistema perfeito
Essa frase em japonês traduz uma sensação que todo mundo conhece mas ninguém gosta de admitir: o mundo é basicamente quebrado. Não de um jeito dramático, só no sentido de que os sistemas que criamos para organizar a vida nunca funcionam na prática. Eu descobri isso da pior forma quando tentei aplicar metodologias ágeis em um projeto de migration de banco de dados legado num hospital. O problema era específico demais pra documentação qualquer. Tínhamos 47 tabelas com restrições de integridade referencial que ninguém documentou, dados duplicados em campos que pareciam independentes, e uma equipe que já tinha aceito que aquilo era "o jeito que funcionava". A workaround que eu usei foi simplesmente ignorar a migração completa e construir uma camada de abstração por cima, com validações assíncronas e retry com backoff exponencial. Demorou duas semanas a mais do que o planejado, mas pelo menos não quebrou o prontuário eletrônico no meio de uma cirurgia de emergência.
Isso acontece porque a maioria dos frameworks e metodologias parte do pressuposto que os dados são limpos e o domínio é simples. Quando você entra num sistema real, especialmente em setores regulamentados como saúde ou financeiro, essa premissa desaba rápido.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que as pessoas geralmente esquecem sobre system design
A primeira lição que eu aprendi foi que clean architecture não é sobre diagramas bonitos. É sobre saber onde colocar aComplexidade inevitável sem que ela exploda quando o sistema vai pro ar. Tenho visto muita gente tentar impor padrões de microserviços em monolitos que mal funcionam, e aí reclamar que a complexidade distribuída é pior que a original. Uma coisa contra-intuitiva que pouca gente admite: às vezes o melhor design é aquele que permite que algo fique feio de propósito. Eu já deixei dois campos duplicados existirem num sistema porque a consolidação ia exigir uma migration de dados que levaria 6 horas de downtime, e o negócio não podia parar. Funciona. Ninguém nota. Até notar.
Limitações que ninguém fala
Se existe algum padrão ou método que funciona perfeitamente, eu nunca vi. Design patterns têm trade-offs que aparecem só quando o tráfego sobe ou os dados crescem. Por exemplo, o Event Sourcing é maravilhoso até você precisar fazer uma query de relatório que cruza 18 aggregates. Aí ele vira um pesadelo de performance. Recomendo uma alternativa quando aplicável: para sistemas com alta variabilidade de carga, considere um modelo híbrido com CQRS simples, separando leituras e escritas sem adicionar complexidade desnecessária. Isso costuma reduzir o tempo de resposta de queries complexas de segundos para milissegundos, dependendo da sua infraestrutura.
O mundo simplesmente não tem solução perfeita. Tem apenas trade-offs que você escolhe conscientemente. E às vezes a escolha certa é admitir que kono sekai wa fukanzen sugiru e continuar trabalhando com o que tem.
