claudiobastos
commented
1 year ago Fluxo que está sendo seguido:
flowchart TD
A[fa:fa-angry Dor] -->|fa:fa-handshake Proposta| B(fa:fa-award Produto)
B --> C1{fa:fa-file-alt PRD}
C1 --> C2{fa:fa-file-alt fa:fa-tasks ASR}
C2 -->|ADR| D1[fa:fa-check-square Go]
C2 -->|ADR| D2[fa:fa-check-square HTTP/2]
C2 -->|ADR| D3[fa:fa-check-square gRPC]
C2 -->|ADR| D4[...]Legenda:
- Dor (um dos itens do Value Proposition Canvas)
- Produto (proposta para sanar a dor)
- PRD: Product Requirements Document
- ASR: Architectural Significant Requirement
- ADR: Architectural Decision Records
Como montar uma ASR
Para construir um ASR, iniciamos nossa análise a partir da especificação do produto, e nesse caso, nossa análise se baseará no PRD.
De maneira geral, para montar documentos ASR para seu produto, podemos seguir dessa forma:
Note que dependendo de aspectos particulares, pode ser necessário considerar mais passos.
Identificação de Requerimentos = Refinamento técnico
O PRD listou os requerimentos usando um vocabulário livre.
Agora precisamos refiná-lo tecnicamente, e para isso vamos extrair seções e mapeá-las em termos de conceitos, tecnologias e critérios.
Conceitos gerais para identificar requisitos:
Avaliação
Após listados, precisamos avaliar os requisitos em função de critérios mais importantes.
Alguns critérios e perguntas de inspeção:
Priorização
Após classificá-los com relação aos critérios do seu interesse, e relacioná-los com relação às suas dependências intrínsecas, necessitamos priorizá-los.
Essa priorização deve servir de guia às discussões que determinarão as decisões finais de desenvolvimento arquitetural, os ADRs, quer serão construídos em momentos posteriores, e não são parte do escopo do ASR.
Documente o ASR
No documento de ASRs, ficarão documentados os items relevantes e avaliações técnicas relevantes associadas aos mesmos.
Estrutura geral do documento
A estrutura de um documento ASR pode variar, mas simplificadamente inclui as seções:
Dicas para construção de um ASR
Exemplo
Identificado: ASR-11 Requiremento: O sistema deve ser capaz de tratar 10,000 usuários concorrentes. Razão: O requerimento é importante porque garante que o sistema é capaz de tratar a carga prevista. Impacto arquitetural: O sistema precisa ser modelado para escalar horizontalmente para poder tratar 10,000 usuários concorrentes. Pode ser necessário o uso de computação em nuvem ou arquitetura distribuida. Dependencias: O sistema precisa se comunicar com um banco de dados.