diretrizes-de-arquitetura-de-software

SKILL.md

---
name: diretrizes-de-arquitetura-de-software
description: Aplique orientações contextuais de arquitetura de software ao analisar limites do sistema, requisitos de qualidade, comunicação, estilos, decisões, riscos ou evolução.
---

# Diretrizes de Arquitetura de Software

Use este rascunho portátil para apoiar o trabalho de arquitetura em diversos domínios de software. Ele não é instalado globalmente. O livro fornece conceitos e trade-offs; este guia os operacionaliza como verificações condicionais. Eles não são comandos de projeto nem substitutos para a intenção do usuário, governança local ou evidências conhecidas do sistema.

## Fluxo de trabalho

1. **Estabeleça contexto e autoridade.** Identifique o domínio, limite do sistema, resultados de negócio, restrições de implantação e dados, capacidades da equipe, evidências conhecidas, desconhecidos e autoridade de decisão. Respeite a autoridade já delegada. Pergunte apenas pelos fatos faltantes que possam alterar o resultado; caso contrário, dê uma recomendação condicional.
2. **Classifique os direcionadores.** Traduza os resultados dos stakeholders em características arquiteturais. Teste cada candidato contra a definição em três partes, decomponha qualidades compostas e priorize um conjunto pequeno.
3. **Mapeie limites e dados.** Identifique responsabilidades funcionais, dependências, transações, propriedade dos dados, acoplamento estático, chamadas em tempo de execução e características em cada limite relevante.
4. **Compare proporcionalmente.** Para uma escolha consequente, compare pelo menos duas opções viáveis contra as prioridades, custos, riscos e evidências declaradas. Não force uma comparação formal para uma mudança pequena e reversível.
5. **Decida com justificativa.** Declare a recomendação ou status, por que ela se encaixa, custos aceitos, suposições e quais evidências causariam reconsideração. Siga a autoridade delegada; não invente portões de aprovação.
6. **Especifique verificações.** Escolha medidas ou funções de adequação proporcionais ao risco. Nomeie seu escopo, sinal, limitações e resposta.

## Regras principais

- Baseie recomendações no contexto ([regras de contexto e prioridade](references/rulebook.md#context-priorities): F01) e respeite a autoridade delegada ([regras de decisão, risco e evolução](references/rulebook.md#decisions-risk-evolution): D03).
- Derive e classifique características a partir de resultados mensuráveis dos stakeholders ([regras de contexto e prioridade](references/rulebook.md#context-priorities): F05, F06, F07, F08, F18).
- Mantenha responsabilidades coesas e limites honestos sobre dependências e acoplamento ([regras de limites](references/rulebook.md#boundaries-coupling-data): F11–F17, S03, S08; [glossário](references/glossary.md)).
- Escolha comunicação para o trabalho; distinga requisição, comando e evento, e projete para falhas ([regras de comunicação](references/rulebook.md#communication-reliability): S06, S09–S13, S15, D08).
- Trate estilos de arquitetura como opções condicionais e compare seus custos ([regras de estilo](references/rulebook.md#style-choice): S01, S16, D06; [guia de estilo](references/style-selection.md)).
- Registre por que decisões consequentes existem e o que as mudaria ([trade-offs](references/rulebook.md#context-priorities): F02; [registros de decisão](references/rulebook.md#decisions-risk-evolution): F03).
- Torne visíveis risco, incerteza e alinhamento de implementação ([regras de risco e evolução](references/rulebook.md#decisions-risk-evolution): D10, D11, D12, D13).
- Governar restrições importantes com verificações que as pessoas entendam ([regras de governança](references/rulebook.md#decisions-risk-evolution): F09, F10).
- Preserve a escolha da equipe dentro da autoridade e restrições reais ([regras de equipe e comunicação](references/rulebook.md#communication-teams): S04, D16, D17, D18).
- Aplique orientações específicas do provedor somente quando o projeto incluir um provedor de modelo ([D15 em rules.json](references/rules.json)).

## Contrato de saída

Retorne: contexto e desconhecidos; recomendação e status; alternativas e custos; implicações de limites, dados e comunicação; evidências e verificações; e um gatilho para reconsideração. Escale o detalhe conforme a consequência da escolha.

## Referências

Para uma tarefa, carregue apenas a categoria relevante em [rules.json](references/rules.json) ou leia sua seção em [rulebook.md](references/rulebook.md), não ambos nem o pacote inteiro. Carregue [style-selection.md](references/style-selection.md) para os nove estilos, [glossary.md](references/glossary.md) para termos baseados em fonte, e [source-map.json](references/source-map.json) para localizar capítulos citados. Prompts sintéticos de avaliação estão em [evaluation-cases.json](references/evaluation-cases.json); eles não foram executados. Método e limitações estão em [method-and-validation.md](references/method-and-validation.md).