Arquitetura de software na prática
Eu passei dois meses refatorando um sistema legado que usava acoplamento direto entre serviço de pagamento e camada de persistência, simplesmente porque ninguém documentou onde ficavam os limites de responsabilidade. A solução não foi teórica — foi identificar que a classe que chamava o gateway de cartão também fazia select em tabela de usuário, algo que deveria estar isolado em um repositório separado. Isso é arquitetura o que é no dia a dia, não o conceito de livro.
O que significa arquitetura o que é para quem trabalha com código
Arquitetura é o conjunto de decisões de organização que definem como módulos, componentes e camadas se comunicam entre si dentro de um sistema. Quando alguém pergunta arquitetura o que é, a resposta curta é: é sobre onde cada coisa mora e por quê. A resposta longa envolve tradeoffs que não aparecem em diagramas bonitos. Decisões arquiteturais incluem coisas como escolher monolito versus microsserviços, decidir se usa Event Sourcing ou CQRS, definir limites de bounded context em DDD, ou simplesmente aceitar que um arquivo monolítico de 50 mil linhas funciona porque ninguém mudou nada em três anos. Cada escolha tem custo. Monolito é mais rápido de desenvolver no início mas vira pesadelo quando o time cresce além de oito pessoas. Microsserviços dão flexibilidade mas adicionam complexidade de rede, deploy e observabilidade que muitos times não estão preparados para sustentar.
Como decidir arquitetura sem cometer erros clássicos
O erro mais comum que eu vejo em projetos reais é começar discutindo tecnologias antes de entender o problema de domínio. Eu já entrei em sala de reunião onde o CTO queria introduzir GraphQL porque viu um vídeo no YouTube, sem perceber que a maior dor do sistema era lentidão em queries joins que nada tinha a ver com a interface. O workaround que usei foi pedir para rodar um explain plan nas três queries mais pesadas do banco antes de qualquer conversa sobre tecnologia. Dois deles eram índices faltando. Resolver isso em uma tarde eliminou a necessidade de qualquer mudança arquitetural. Para tomar decisões arquiteturais que realmente funcionam, você precisa responder quatro perguntas antes de desenhar qualquer diagrama: qual é a carga esperada no primeiro ano, quantas pessoas vão tocar o código depois de seis meses, qual é o custo de rollback se algo quebrar em produção, e quanto tempo o time leva para fazer deploy hoje. Se o tempo de deploy é menor que dez minutos, mudar para microsserviços provavelmente não vale a pena. Se o custo de rollback é alto porque não há backup consistente dos dados, investir em event sourcing faz mais sentido do que otimizar cache.
Padrões arquiteturais que funcionam e onde falham
Camadas (presentation, business, data access) são o padrão mais simples e geralmente o mais adequado para sistemas que não precisam escalar horizontalmente. Eu mantive um sistema rodando por quatro anos com essa estrutura usando aproximadamente sessenta desenvolvedores, todos sabendo exatamente onde procurar qualquer funcionalidade. O limite prático é que quando você ultrapassa cem mil linhas em um único módulo de negócio, a coesão começa a cair independentemente de quantas subdivisões você criar. Microsserviços funcionam quando times diferentes precisam fazer deploy em velocidades independentes e o domínio naturalmente se separa em bounded contexts. O problema é que a comunicação entre serviços adiciona latência, pontos de falha e complexidade de teste que multiplicam o tempo de desenvolvimento em cerca de trinta a cinquenta por cento comparado a um monolito bem estruturado. Eu vi equipes reduzirem o lead time de feature de duas semanas para três dias depois da migração, mas o custo de manter a consistência eventual em transações distribuídas consumia o equivalente a dois engenheiros em tempo integral.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Event Sourcing é poderoso quando a auditoria completa de todas as alterações é requisito obrigatório, como em sistemas financeiros ou de saúde. A desvantagem prática é que a reconstrução de estado a partir do log de eventos pode levar de quinze minutos a várias horas dependendo do volume, e queries analíticas complexas ficam impossíveis sem materialized views ou data warehouse separado. Uma solução híbrida que funcionou bem para mim foi usar Event Sourcing apenas para eventos de negócio críticos e manter estado atualizado em tabelas normais sincronizadas via outbox pattern.
Sinais de que sua arquitetura precisa mudar
Se o tempo de deploy para produção ultrapassa meia hora consistentemente, se desenvolvedores levam mais de dois dias para integrar changes de outras equipes, ou se bugs em um módulo afetam funcionalidades completamente não relacionadas que deveriam estar isoladas, esses são sinais concretos de que a arquitetura atual não está mais servindo ao domínio. A métrica mais útil que eu uso é medir o ciclo de feedback: quanto tempo leva desde escrever código até ver se funciona em produção. Se esse ciclo ultrapassa vinte e quatro horas, alguma mudança estrutural é necessária independentemente de preferências pessoais. O contraponto importante é que mudar arquitetura por mudar não resolve problemas. Muitas equipes entraram em círculos viciados de refatoração constante sem identificar que a dor real era código espaguete em uma única classe, algo que uma subdivisão em camadas não resolve completamente. O workaround que implementamos foi fazer profiling de temperatura nos módulos mais quentes do sistema por uma semana antes de qualquer discussão sobre padrões arquiteturais. Quase sempre encontramos variáveis globais mal encapsuladas ou estado compartilhado não thread-safe como causa raiz.
Quando arquitetar não é a solução certa
Arquitetura bem intencionada em projetos pequenos ou protótipos pode adicionar complexidade desnecessária que custa de duas a três semanas de desenvolvimento sem benefício mensurável. Se o sistema vai ser usado por menos de mil usuários concurrentes, se o ciclo de vida esperado é menor que doze meses, ou se a equipe tem menos de quatro pessoas, monolito simples com testes automatizados cobre cento e oitenta por cento dos requisitos com metade do esforço. Eu pessoalmente recomendo evitar qualquer decisão arquiteturals sofisticadas até ter dados reais de uso, porque a maioria das estimativas iniciais de escala estão erradas em pelo menos uma ordem de grandeza. A alternativa mais pragmática para equipes sobrecarregadas é adotar a lei de Conway de forma explícita: organizar o sistema de acordo com a comunicação que já existe entre times, não com diagramas ideais. Se dois grupos precisam conversar diariamente para entregar qualquer feature, mantê-los em módulos separados no mesmo código é mais eficiente do que forçar integração através de APIs que ninguém usa. Eu já vi essa abordagem reduzir o lead time de entrega em aproximadamente quarenta por cento em seis meses, sem nenhuma mudança tecnológica.
O que eu aprendi após dezessete anos escrevendo arquitetura é que as melhores decisões são aquelas que alguém pode explicar em uma frase para um desenvolvedor júnior sem precisar de diagramas. Se a explicação exige slides, slides, provavelmente a arquitetura está mais complicada do que necessário. O objetivo final não é criar um sistema perfeito, mas um sistema onde qualquer pessoa na equipe consegue fazer deploy, debugar problemas e adicionar features sem depender de especialistas que conhecem cada detalhe interno.
