Jean Pierre Lessa e Santos Ferreira analisa que decisões de arquitetura de sistemas são, na essência, apostas sobre o futuro. Toda escolha de como estruturar componentes, dados e integrações carrega premissas implícitas sobre como o sistema vai crescer, quem vai usá-lo e que tipo de mudanças serão necessárias. Projetar sem considerar explicitamente essas premissas é como construir sem saber para que tamanho de família a casa está sendo planejada.
Neste artigo, serão explorados os fatores que tornam a arquitetura de sistemas uma decisão estratégica e como as escolhas feitas no presente podem influenciar a capacidade de evolução e adaptação das soluções ao longo do tempo.
Toda arquitetura é uma aposta: você sabe em que está apostando?
A arquitetura ideal para um sistema com mil usuários é frequentemente diferente da arquitetura ideal para o mesmo sistema com um milhão de usuários, e tentar usar a segunda desde o início pode ser tão prejudicial quanto não se preparar para o crescimento. O excesso de engenharia antecipada consome tempo e recursos em complexidade que pode nunca se justificar, enquanto a ausência completa de planejamento para escala cria sistemas que precisam ser reescritos no momento mais inconveniente possível, como pondera Jean Pierre Lessa e Santos Ferreira.
O equilíbrio está em identificar quais decisões são realmente difíceis de reverter depois e quais podem ser ajustadas conforme a necessidade real se revela. Escolhas sobre modelo de dados fundamental, limites entre componentes principais e estratégias de armazenamento tendem a ser caras de mudar depois. Escolhas sobre detalhes de implementação dentro desses limites costumam ser mais flexíveis e podem evoluir junto com o sistema sem grandes traumas.
Microsserviços ou monólitos: a pergunta certa é sobre tecnologia ou sobre fronteiras?
Muito se discute sobre microsserviços versus monólitos como se fosse uma escolha puramente técnica, quando, na verdade, a questão central é sobre fronteiras de responsabilidade. Um monólito bem modularizado, com fronteiras internas claras entre diferentes domínios de negócio, pode ser mais saudável do que um conjunto de microsserviços com fronteiras mal definidas e dependências emaranhadas, observação que Jean Pierre Lessa e Santos Ferreira reforça.
A pergunta que realmente importa não é qual padrão arquitetural adotar, mas onde estão as fronteiras naturais do negócio que o sistema representa. Alguns sinais ajudam a identificar essas fronteiras:
- Domínios que mudam por razões diferentes, com ritmos próprios de evolução que não dependem das mesmas decisões de negócio.
- Áreas operadas por equipes diferentes, onde a separação reduz a necessidade de coordenação constante entre times com prioridades distintas.
- Componentes com requisitos de escala muito distintos, que se beneficiam de poder crescer ou ser otimizados de forma independente.
Entender essas fronteiras antes de escolher a tecnologia evita que decisões de infraestrutura criem rigidez onde deveria existir flexibilidade, independentemente de essa separação acontecer dentro de um mesmo código-base ou entre serviços independentes.
Sistemas que sobrevivem às pessoas que os criaram
Um teste valioso para qualquer decisão de arquitetura é imaginar como o sistema será compreendido por pessoas que não participaram de sua criação. Sistemas que dependem do conhecimento tácito de quem os construiu se tornam progressivamente mais arriscados conforme essas pessoas mudam de função ou deixam a organização, levando consigo o entendimento que nunca foi documentado. Jean Pierre Lessa e Santos Ferreira trata esse teste como uma das verificações mais simples e mais reveladoras que uma equipe pode fazer.
Arquiteturas que priorizam clareza, mesmo quando isso significa abrir mão de alguma elegância técnica, tendem a envelhecer melhor. Nomenclatura consistente, documentação que explica não apenas o que o sistema faz, mas por que foi projetado daquela forma, e estruturas que seguem convenções amplamente conhecidas reduzem a dependência de heróis individuais e tornam o sistema mais resiliente a longo prazo.
A arquitetura como reflexo de prioridades organizacionais
Toda arquitetura de sistemas, observada com atenção suficiente, revela as prioridades reais de quem a projetou. Sistemas em que a segurança foi tratada como prioridade desde o início parecem diferentes de sistemas em que ela foi adicionada depois. O mesmo vale para escalabilidade, manutenibilidade e experiência do usuário. Para Jean Pierre Lessa e Santos Ferreira, reconhecer isso é um convite para que as prioridades sejam definidas conscientemente antes que a arquitetura as defina por omissão.
Autor: Diego Rodríguez Velázquez
