System design

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

System Design é o raciocínio feito antes de qualquer linha de código. Define o que o sistema precisa fazer, em que condições precisa funcionar e quais trade-offs (trocas) são aceitáveis. Implementação sem esse raciocínio vira retrabalho quando o primeiro gargalo aparece.

System Design não descreve como o código é escrito. Descreve o sistema visto de fora:

Quando essas perguntas ficam respondidas antes da implementação, o código tem critério de avaliação. Sem elas, cada decisão técnica vira opinião.

Todo sistema tem dois tipos de requisito que precisam ser explícitos.

Requisitos funcionais vêm quase sempre do produto. Requisitos não-funcionais precisam ser perguntados:

Sem essas respostas, o design assume valores arbitrários e descobre tarde que não são os corretos.

Decompor um sistema tem uma ordem que funciona:

Entidades → Fluxos → Fronteiras → Contratos → Componentes

Entidades: os substantivos do domínio (Pedido, Usuário, Produto, Pagamento). Aparecem na linguagem do negócio antes de aparecer em qualquer tabela.

Fluxos: os verbos que atravessam entidades (criar pedido, confirmar pagamento, enviar notificação). Cada fluxo tem início, meio e fim rastreáveis.

Fronteiras: onde um fluxo deixa uma área e entra em outra. Fronteiras viram interfaces no código e pontos de observabilidade em produção.

Contratos: o que cada fronteira recebe e retorna. Contrato explícito reduz acoplamento entre componentes.

Componentes: a tradução dos blocos anteriores em partes implantáveis. Só nessa etapa aparecem decisões de linguagem, banco e infraestrutura.

Pular etapas cria sistemas onde a implementação não reflete o domínio. Seguir a ordem mantém a linguagem do negócio visível na arquitetura.

Sistema real tem restrições. Não existe solução que otimiza tudo ao mesmo tempo. Os trade-offs mais comuns:

O trabalho de design é escolher conscientemente, não evitar a escolha. Evitar a escolha leva ao default da ferramenta, que pode não ser o default do problema.

Começa: assim que o problema é conhecido. Antes de escolher framework, banco ou linguagem.

Termina: quando existem respostas para as quatro perguntas:

Respondidas essas perguntas, o próximo passo é patterns.md (padrões táticos), architecture.md (organização de código) e scaling.md (técnicas de escala). Aprofundamento em SLA, CAP, modelos de consistência e capacity planning fica em system-design-advanced.md.

Desenvolvido por @thiagocajadev · Fork baseado no repositório pmndrs/docs · Poimandres.