Do pedido ao sistema
Imagine um serviço de matrículas. O navegador envia um pedido, o backend valida os dados, consulta o curso, registra a matrícula e confirma o resultado. Arquitetura descreve as decisões que organizam esse caminho: quais partes existem, que responsabilidades têm, como se comunicam e em que ambiente rodam.
Uma decisão merece atenção arquitetural quando afeta mais de um módulo, muda um atributo importante — como segurança ou disponibilidade — ou torna mudanças futuras mais caras. Escolher o nome de uma variável costuma ser local. Decidir que todos os pagamentos passam por um contrato comum afeta limites e evolução do sistema.
Abrir diagrama em tamanho original
Uma pergunta antes da tecnologia
Liste primeiro necessidades e restrições: quem usa o sistema, quais dados são sensíveis, qual volume é esperado e como ele será operado. Só então compare alternativas. Arquitetura é um conjunto coerente de decisões para essas condições; não é uma receita que serve para todo produto.
Recupere: que mudança atravessa várias partes do sistema e, por isso, merece uma decisão explícita?
Pratique com /aprender
/aprender Ajude-me a analisar a arquitetura de um serviço de matrículas. Apresente um requisito por vez (usuário, regra, dados, operação), peça minha hipótese antes de explicar e diferencie uma decisão local de código de uma decisão que afeta limites, dependências ou qualidade do sistema. Termine pedindo que eu justifique um trade-off sem escolher tecnologia por hype.