Processo de Arquitetura de Software¶

1. Documento de Referência de Processo¶

Versão: 1.0 Escopo: Define o processo de Arquitetura de Software a ser executado após a conclusão dos processos de engenharia de requisitos.

2. Objetivo¶

Este documento define o pipeline de Arquitetura de Software adotado, com técnicas, artefatos, nomenclatura e regras de rastreabilidade simplificadas, permitindo replicar o processo de forma consistente em qualquer novo projeto, sem overhead desproporcional ao tamanho da equipe (1 pessoa).

3. Visão Geral do Pipeline¶

FASE 1: Análise Arquitetural (enxuta) -----> Identificar ASRs relevantes 
FASE 2: Síntese ---------------------------> Escolha de stack + ADR leve 
FASE 3: Documentação ----------------------> C4 reduzido + arc42 reduzido

4. FASE 1 — Análise Arquitetural¶

4.1. Objetivo¶

Filtrar, dos Requisitos Funcionais e Não Funcionais já documentados (02-Requisitos-Funcionais.md, do processo de ER), quais realmente forçam decisões estruturais.

4.2. Critério de filtragem¶

Considerar ASR apenas requisitos que:

Têm alto risco técnico ou impacto em múltiplos módulos;
Envolvem atributos de qualidade críticos: desempenho, segurança, manutenibilidade (priorizados devido ao seu impacto crítico na viabilidade de projetos conduzidos por um único desenvolvedor).

4.4. Template¶

## ASR-000

- `<` **Backward:** [RF-000 ou RNF-000]
- **Preocupação:** [1 frase descrevendo o risco/exigência]
- **Decisão rápida:** [direção a seguir, sem cenário formal]

5.1. Saída da Fase 1¶

Documento 02-Decisoes-ASRs.md com a lista enxuta de ASRs — input direto da Fase 2.

6. FASE 2 — Síntese (ADR leve)¶

6.1. Objetivo¶

Escolher pragmaticamente estilo arquitetural e tecnologias, registrando apenas as decisões que não são óbvias — decisões triviais não precisam de ADR.

6.4. Template¶

## 7. ADR-000

- **Decisão:** [...]
- `<` **Backward:** [RF-000 / RNF-000 / ASR-000]
- **Por quê:** [motivo direto, 1-2 linhas]
- **Trade-off:** [o que se perde em troca]
- `>` **Forward:** [Container C4 / TASK-000]

7.1. Saída da Fase 2¶

Documento 03-Decisoes-ADRs.md com a registro de todas as ADRs — input direto da Fase 3.

8. FASE 3 — Documentação (C4 reduzido + arc42 reduzido)¶

8.1. Objetivo¶

Documentar a arquitetura com o mínimo de views necessárias para manter uma visão clara, sem manutenção excessiva.

8.2. Escopo do C4 usado¶

Nível	Uso
Nível 1 — Contexto	Incluído
Nível 2 — Container	Incluído
Nível 3 — Componente	Omitido
Nível 4 — Código	Omitido

8.3. Template de diagrama de Contexto¶

C4Context
    title Diagrama de Contexto - [Nome do Sistema]

    Person(ator1, "[Nome do Ator]", "[Descrição]")

    System(sistema, "[Nome do Sistema]", "[Descrição]")

    System_Ext(externo1, "[Sistema Externo]", "[Descrição]")

    Rel(ator1, sistema, "[ação]")
    Rel(sistema, externo1, "[ação]")

8.4. Template de diagrama de Container¶

C4Container
    title Diagrama de Container - [Nome do Sistema]

    Person(usuario, "[Ator]", "[Descrição]")

    Container_Boundary(sistema, "[Nome do Sistema]") {
        Container(api, "[Nome]", "[Tecnologia]", "[Descrição]")
        Container(frontend, "[Nome]", "[Tecnologia]", "[Descrição]")
        ContainerDb(db, "[Nome]", "[Tecnologia]", "[Descrição]")
    }

    System_Ext(externo1, "[Sistema Externo]", "[Descrição]")

    Rel(usuario, frontend, "[ação]", "[protocolo]")
    Rel(frontend, api, "[ação]", "[protocolo]")
    Rel(api, db, "[ação]", "[protocolo]")

8.5. Escopo do arc42 usado¶

1. Metas e Restrições      ← reaproveita meta raiz (KAOS) + restrições de equipe
2. Contexto                ← C4 Nível 1
3. Decisões Arquiteturais  ← lista de ADRs
4. Visão de Blocos         ← C4 Nível 2 (Container)
5. Riscos/Dívida Técnica   ← lista simples de riscos aceitos e débitos conhecidos

8.6. Saída da Fase 3¶

Arquitetura/
 00-Visao-Geral-DAS.md
 01-Contexto-Container.md
 02-Decisoes-ASRs.md
 03-Decisoes-ADRs.md
 04-Riscos-Dívida-Tecnica.md

9. Convenção Geral de Nomenclatura de IDs¶

Camada	Prefixo	Exemplo
Requisito Arquiteturalmente Significativo	`ASR-`	ASR-001
Registro de Decisão Arquitetural	`ADR-`	ADR-001
Risco	`RISCO-`	RISCO-001
Dívida Técnica	`DIVIDA-`	DIVIDA-001

10. Regra de Rastreabilidade Backward/Forward¶

Mantida a mesma convenção do processo de ER:

Campo	Símbolo	Pergunta	Aponta para
Backward	`<`	De onde esta decisão veio?	RF/RNF/ASR de origem
Forward	`>`	O que esta decisão gera?	Container (C4) / Task de implementação

10.1. Cadeia completa (ER + Arquitetura)¶

RF / RNF (Documento de Requisitos)
        ↓ backward
   ASR-000 (Requisito Arquiteturalmente Significativo)
        ↓ backward
   AD-000 (Decisão Arquitetural)
        ↓ forward
   Contexto/Container (C4)

11. Fluxograma Resumido do Processo¶

1. Filtrar Requisitos → identificar ASRs relevantes (Fase 1)
        ↓
2. Escolher stack/estilo pragmaticamente (Fase 2)
        ↓
3. Registrar decisões não óbvias como AD (Fase 2)
        ↓
4. Diagramar Contexto e Container (Fase 3)
        ↓
5. Consolidar em arc42 reduzido (Fase 3)
        ↓
6. Listar riscos e dívidas técnicas conhecidas (Fase 3)
        ↓
7. Artefatos prontos → início da implementação

12. Resumo Executivo¶

Filtrar ASRs relevantes a partir dos RF/RNF já documentados na ER
Decidir pragmaticamente, registrando só o que não é óbvio (AD leve)
Documentar com C4 reduzido + arc42 reduzido
Toda decisão declara Backward (origem no RF/RNF) e Forward (destino na implementação)