A pressão para desenhar uma solução “preparada para tudo” cria frequentemente sistemas mais caros e difíceis de alterar. Pragmatismo significa investir onde o custo de estar errado é alto e adiar escolhas reversíveis até existir informação suficiente.
Restrições antes de padrões
Volume, disponibilidade, competências da equipa, requisitos legais e velocidade de entrega definem o espaço da solução. Um padrão tecnicamente elegante pode ser uma má escolha quando ignora estas restrições.
Separar decisões reversíveis
Uma escolha fácil de alterar não merece semanas de análise. Já limites entre domínios, modelos de dados centrais e dependências de fornecedor exigem cuidado, porque o seu custo de mudança cresce com o tempo.
Arquitectura é gerir o custo da mudança, não eliminar a mudança.
Modularidade com propósito
Começar com uma aplicação modular é muitas vezes mais eficiente do que distribuir prematuramente componentes. Fronteiras bem definidas permitem extrair serviços quando escala, equipas ou isolamento o justificarem.
Registar e validar
Registos curtos de decisão preservam contexto. Métricas técnicas e de negócio mostram se as hipóteses continuam válidas. Assim, a arquitectura transforma-se num processo de aprendizagem, não num documento congelado.