Terminei recentemente Arquitetura de Software: As Partes Difíceis (Neal Ford, Mark Richards e outros) e foi um divisor de águas na forma como penso engenharia de software. A principal lição que levo para os meus projetos é que, na arquitetura moderna, a palavra "depende" não é uma fuga — é a resposta mais técnica e madura que um desenvolvedor pode dar.
O livro desconstrói a busca por uma solução definitiva e coloca o foco onde a engenharia de fato acontece: nos trade-offs. Ao projetar sistemas e estruturar backend, fica claro que não existem "melhores práticas" universais — existem apenas escolhas e suas consequências dentro de um contexto específico.
O mito do desacoplamento total
Separar sistemas em microsserviços ou módulos menores não elimina a complexidade — apenas a move de lugar. O acoplamento sempre vai existir; o desafio técnico real é escolher qual tipo de acoplamento o sistema pode tolerar (estático vs. dinâmico, por exemplo). Perseguir "zero acoplamento" é perseguir um fantasma.
Dados são a verdadeira parte difícil
Quebrar código em pedaços menores é relativamente simples com os frameworks de hoje. A barreira arquitetural de verdade é gerenciar transações e consistência de dados em sistemas distribuídos sem destruir a performance. É justamente aí que a maioria dos projetos de decomposição de monólitos trava.
Documentar o porquê
Um dos pontos que mais gostei foi o valor de registrar Architecture Decision Records (ADRs). O que faz um design ser bom hoje pode não fazer sentido amanhã, e o contexto documentado por trás de uma decisão economiza horas de discussão e refatoração no futuro — principalmente quando quem decidiu já não está mais no time.
Essa leitura mudou minha abordagem prática para a construção de software. Meu foco evoluiu de simplesmente "fazer funcionar" para analisar criticamente a granularidade dos serviços, os padrões de comunicação entre eles e como cada decisão impacta a escalabilidade e a manutenção do sistema no longo prazo.