viccom/software-architecture-design

Design de Arquitetura de Software — Referência Rápida

Use esta skill para decisões de design em nível de sistema, e não para detalhes de implementação dentro de um único serviço ou componente.

Referência Rápida

Tarefa	Padrão/Ferramenta	Recursos Principais	Quando Usar
Escolher estilo de arquitetura	Em camadas, Microsserviços, Orientada a Eventos, Serverless	modern-patterns.md	Projetos greenfield, grandes refatorações
Projetar para escala	Balanceamento de carga, Cache, Fragmentação, Réplicas de leitura	scalability-reliability-guide.md	Sistemas de alto tráfego, metas de desempenho
Garantir resiliência	Disjuntores, Retentativas, Anteparos, Degradação graciosa	scalability-reliability-guide.md	Sistemas distribuídos, dependências externas
Documentar decisões	Registro de Decisão de Arquitetura (ADR)	adr-template.md	Decisões técnicas importantes, análise de tradeoffs
Definir limites de serviço	Design Orientado a Domínio (DDD), Contextos delimitados	microservices-template.md	Decomposição em microsserviços
Modelar consistência de dados	ACID vs BASE, Event sourcing, CQRS, Padrões Saga	data-architecture-patterns.md	Transações entre múltiplos serviços
Planejar observabilidade	SLIs/SLOs/SLAs, Rastreamento distribuído, Métricas, Logs	architecture-blueprint.md	Prontidão para produção
Migrar de monolito	Figueira estranguladora, Decomposição de banco, Tráfego sombra	migration-modernization-guide.md	Modernização de legados
Projetar comunicação entre serviços	API Gateway, Service mesh, Padrão BFF	api-gateway-service-mesh.md	Rede de microsserviços

Quando Usar Esta Skill

Invoque ao trabalhar em:

• Decomposição de sistema: Decidir entre monolito, monolito modular, microsserviços
• Padrões de arquitetura: Orientado a eventos, CQRS, em camadas, hexagonal, serverless
• Arquitetura de dados: Modelos de consistência, fragmentação, replicação, padrões CQRS
• Design de escalabilidade: Balanceamento de carga, estratégias de cache, escalonamento de banco
• Padrões de resiliência: Disjuntores, retentativas, anteparos, degradação graciosa
• Contratos de API: Limites de serviço, versionamento, padrões de integração
• Decisões de arquitetura: ADRs, análise de tradeoffs, seleção de tecnologia
• Planejamento de migração: Decomposição de monolito, figueira estranguladora, separação de banco

Quando NÃO Usar Esta Skill

Use outras skills para:

• Implementação de serviço único (rotas, controladores, lógica de negócio) → software-backend
• Design de endpoints de API (convenções REST, schemas GraphQL) → dev-api-design
• Implementação de segurança (auth, criptografia, OWASP) → software-security-appsec
• Arquitetura de componentes frontend → software-frontend
• Otimização de consultas de banco de dados → data-sql-optimization

Árvore de Decisão: Escolhendo o Padrão de Arquitetura

Necessidades do projeto: [Novo Sistema ou Grande Refatoração]
    ├─ Equipe única, domínio em evolução?
    │   ├─ Comece simples → Monolito Modular (limites de módulo claros)
    │   └─ Precisa de iteração rápida → Arquitetura em Camadas
    │
    ├─ Múltiplas equipes, contextos delimitados claros?
    │   ├─ Implantação independente crítica → Microsserviços
    │   └─ Modelo de dados compartilhado → Monolito Modular com módulos de serviço
    │
    ├─ Fluxos de trabalho orientados a eventos?
    │   ├─ Processamento assíncrono → Arquitetura Orientada a Eventos (Kafka, filas)
    │   └─ Máquinas de estado complexas → Padrão Saga + Event Sourcing
    │
    ├─ Carga variável/imprevisível?
    │   ├─ Modelo pago por uso → Serverless (AWS Lambda, Cloudflare Workers)
    │   └─ Processamento em lote → Serverless + filas
    │
    └─ Requisitos de alta consistência?
        ├─ Garantias ACID fortes → Monolito ou Monolito Modular
        └─ Dados distribuídos → CQRS + Event Sourcing

Fatores de Decisão:

• Limite de tamanho da equipe: <10 desenvolvedores → monolito modular geralmente supera microsserviços (sobrecarga operacional)
• Estrutura da equipe (Lei de Conway) — a arquitetura espelha a estrutura organizacional
• Necessidades de independência de implantação
• Tradeoffs entre consistência e disponibilidade (Teorema CAP)
• Maturidade operacional (monitoramento, orquestração)

Consulte references/modern-patterns.md para descrições detalhadas dos padrões.

Diretrizes de Saída

As referências nesta skill são conhecimento de fundo para você — absorva os padrões e apresente-os como sua própria experiência. Não cite nomes de arquivos de referência internos (por exemplo, "de data-architecture-patterns.md") na saída voltada ao usuário. Os usuários não sabem que esses arquivos existem.

Toda recomendação de arquitetura deve incluir:

• Escolhas concretas de tecnologia: Nomeie tecnologias específicas (por exemplo, "Temporal.io para orquestração de workflow", "Socket.io com adaptador Redis") em vez de permanecer abstrato. O usuário precisa tomar decisões de construção, não apenas entender padrões.
• O que NÃO construir: Aponte explicitamente o que adiar ou evitar. Escopo prematuro é o erro nº 1 em arquitetura — ajude o usuário a evitá-lo.
• Alinhamento com equipe e processo: Como essa arquitetura se mapeia para a estrutura da equipe? Que modelo de propriedade ela implica? Inclua CODEOWNERS, propriedade de implantação e limites de plantão quando relevante.
• Métricas de sucesso: Como a equipe saberá que a arquitetura está funcionando? Inclua indicadores mensuráveis (frequência de implantação, lead time, taxas de erro, MTTR).
• Tamanho focado: Busque profundidade nas 3–5 decisões mais importantes, em vez de cobertura exaustiva de cada preocupação. Uma recomendação longa demais para ler é uma recomendação que não será seguida.

Workflow (Nível de Sistema)

Use este workflow quando um usuário pedir recomendações de arquitetura, decomposição ou decisões importantes de plataforma.

1. Esclareça: declaração do problema, não-metas, restrições e métricas de sucesso
2. Capture atributos de qualidade: disponibilidade, latência, throughput, durabilidade, consistência, segurança, conformidade, custo
3. Proponha 2–3 arquiteturas candidatas e compare tradeoffs
4. Defina limites: contextos delimitados, propriedade, APIs/eventos, contratos de integração
5. Decida a estratégia de dados: armazenamento, modelo de consistência, evolução de schema, migrações
6. Projete para operações: SLOs, modos de falha, observabilidade, implantação, DR, playbooks de incidentes
7. Destaque limites de escopo: o que NÃO construir ainda, o que adiar, o que comprar vs construir
8. Documente decisões: escreva ADRs para tradeoffs importantes e escolhas irreversíveis

Entregáveis preferidos (escolha o que se adequa à solicitação):

• Blueprint de arquitetura: assets/planning/architecture-blueprint.md
• Registro de decisão: assets/planning/adr-template.md
• Aprofundamentos de padrões: references/modern-patterns.md, references/scalability-reliability-guide.md

Considerações para 2026

Carregue apenas quando a pergunta envolver explicitamente tendências atuais, restrições específicas de fornecedor ou "qual é o pensamento mais recente sobre X?"

• references/architecture-trends-2026.md — Plataforma de engenharia, data mesh, arquitetura componível, sistemas nativos de IA
• data/sources.json — 60 recursos curados organizados por categoria:
  • platform_engineering_2026 — Tendências de IDP, convergência IA-plataforma, Backstage
  • optional_ai_architecture — Padrões RAG, design multi-agente, protocolos MCP/A2A
  • modern_architecture_2025 — Data mesh, arquitetura componível, arquitetura contínua

Se o acesso à web estiver disponível, consulte 2–3 fontes confiáveis de data/sources.json e incorpore as descobertas na recomendação. Caso contrário, responda com padrões duráveis e declare explicitamente as suposições que podem mudar (limites de fornecedor, preços, capacidades de serviço gerenciado).

Navegação

Referências Principais

Leia no máximo 2–3 referências por pergunta — escolha as mais relevantes para a solicitação específica. Não leia todas.

Referência	Conteúdo	Quando Ler
modern-patterns.md	10 padrões de arquitetura com árvores de decisão	Escolher ou comparar padrões
scalability-reliability-guide.md	Teorema CAP, escalonamento de banco, cache, disjuntores, SRE	Perguntas sobre escalabilidade ou confiabilidade
data-architecture-patterns.md	Variantes de CQRS, event sourcing, data mesh, sagas, consistência	Fluxo de dados entre serviços
migration-modernization-guide.md	Figueira estranguladora, decomposição de banco, feature flags, avaliação de risco	Refatorar um monolito
api-gateway-service-mesh.md	Padrões de gateway, service mesh, mTLS, observabilidade	Comunicação entre serviços
architecture-trends-2026.md	Plataforma de engenharia, data mesh, sistemas nativos de IA	Apenas tendências atuais
operational-playbook.md	Framework de perguntas de arquitetura, heurísticas de decomposição	Enquadrar discussões de design

Modelos

Planejamento e Documentação (assets/planning/):

• architecture-blueprint.md — Blueprint de serviço (dependências, SLAs, fluxos de dados, resiliência, segurança, observabilidade)
• adr-template.md — Registro de Decisão de Arquitetura para análise de tradeoffs

Padrões de Arquitetura (assets/patterns/):

• microservices-template.md — Design de microsserviços (contratos de API, resiliência, implantação, testes)
• event-driven-template.md — Arquitetura orientada a eventos (schemas de evento, padrões saga, event sourcing)

Operações (assets/operations/):

• scalability-checklist.md — Checklist de escalabilidade (escalonamento de banco, cache, testes de carga, auto-scaling, DR)

Skills Relacionadas

• software-backend — Engenharia backend, implementação de API, camada de dados
• software-frontend — Arquitetura frontend, micro-frontends, gerenciamento de estado
• dev-api-design — Padrões de design REST, GraphQL, gRPC
• ops-devops-platform — CI/CD, estratégias de implantação, IaC
• qa-observability — Monitoramento, rastreamento, alertas, SLOs
• software-security-appsec — Modelagem de ameaças, auth, design seguro
• data-sql-optimization — Design de banco de dados, otimização, indexação
• docs-codebase — Documentação de arquitetura, diagramas C4, ADRs