Name: adr-template
Author: ricardobalbino

Prompt file imported from ricardobalbino/code-dynamics (.github/prompts/adr-template.prompt.md). Fill in {{AVANADE_ARCHITECTURE_TEMPLATE}}, {{AVANADE_MEMORY_ARCHITECT_WILSON}}, {{AVANADE_TASK_ARCHITECTURE_QUALITY}} before use. Copyright stays with the author.

---

⚠️ [Nome do Cliente] - CONTEXTO OBRIGATÓRIO Antes de executar, ler: [Projeto]-knowledge-base.md, [Projeto]-discovery.md, especificacao-simulador-notion.md, d365-config.yaml em .avanade-method/docs/ e .avanade-method/configs/. Projeto: D365 CE + Power Pages + Azure Functions + TOTVS/Datasul.

📋 O que é este Artefato?

Este template fornece uma estrutura padronizada para documentar decisões arquiteturais importantes. ADRs são documentos imutáveis que registram:

O que foi decidido
Por que essa decisão foi tomada
Quando a decisão foi feita
Quais alternativas foram consideradas
Quais trade-offs foram aceitos

🎯 Quando Usar

Use este template quando:

✅ Tomar uma decisão arquitetural significativa (tecnologia, padrão, infraestrutura)
✅ Escolher entre múltiplas opções técnicas com trade-offs claros
✅ Definir padrões que impactam múltiplos componentes/times
✅ Documentar escolhas que afetam NFRs (performance, segurança, escalabilidade)
✅ Reverter ou substituir uma decisão arquitetural anterior

Não use para decisões triviais ou de implementação de baixo nível.

📖 Estrutura do Template

ADR-[NÚMERO]: [TÍTULO DA DECISÃO]

# ADR-[NÚMERO]: [Título Conciso da Decisão]

**Status**: [Proposto | Aceito | Rejeitado | Depreciado | Substituído por ADR-XXX]  
**Data**: YYYY-MM-DD  
**Autor(es)**: [Nome(s) do(s) Arquiteto(s)]  
**Stakeholders**: [Times/pessoas impactados]  
**Decisor**: [Quem aprovou]

---

## 📌 Contexto

[Descreva o contexto que motivou esta decisão. O que está acontecendo? Por que precisamos decidir agora?]

**Fatores contextuais**:
- Requisitos de negócio relevantes
- Constraints técnicos existentes
- Deadlines ou dependências
- Estado atual da arquitetura

---

## 🎯 Decisão

**Decisão**: [Uma frase clara do que foi decidido]

[Descreva a decisão em detalhes: o que será implementado, como funcionará, quais tecnologias/padrões serão usados]

---

## 🔍 Alternativas Consideradas

### Opção 1: [Nome da Opção]
**Descrição**: [Como funcionaria]
**Prós**:
- ✅ [Vantagem 1]
- ✅ [Vantagem 2]

**Contras**:
- ❌ [Desvantagem 1]
- ❌ [Desvantagem 2]

---

### Opção 2: [Nome da Opção]
**Descrição**: [Como funcionaria]
**Prós**:
- ✅ [Vantagem 1]
- ✅ [Vantagem 2]

**Contras**:
- ❌ [Desvantagem 1]
- ❌ [Desvantagem 2]

---

### Opção 3: [Nome da Opção] (Escolhida)
**Descrição**: [Como funcionaria]
**Prós**:
- ✅ [Vantagem 1]
- ✅ [Vantagem 2]

**Contras**:
- ❌ [Desvantagem 1]
- ❌ [Desvantagem 2]

---

## ⚖️ Análise de Trade-offs

| Critério | Opção 1 | Opção 2 | Opção 3 (Escolhida) |
|----------|---------|---------|---------------------|
| Performance | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| Scalability | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Cost | 💰💰💰 | 💰 | 💰💰 |
| Complexity | 🔧🔧 | 🔧🔧🔧🔧 | 🔧🔧🔧 |
| Time to Market | 🚀🚀 | 🚀🚀🚀🚀 | 🚀🚀🚀 |
| Maintainability | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |

---

## 💡 Justificativa

[Explique POR QUE a opção escolhida é a melhor dado o contexto. Quais fatores foram mais importantes?]

**Fatores decisivos**:
1. [Razão principal #1]
2. [Razão principal #2]
3. [Razão principal #3]

---

## 📊 Consequências

### Positivas
- ✅ [Benefício esperado 1]
- ✅ [Benefício esperado 2]
- ✅ [Benefício esperado 3]

### Negativas (Trade-offs Aceitos)
- ⚠️ [Trade-off 1 - como mitigar]
- ⚠️ [Trade-off 2 - como mitigar]

### Riscos
- 🚨 **[Risco 1]**: [Como mitigar]
- 🚨 **[Risco 2]**: [Como mitigar]

---

## 🏗️ Implementação

### Componentes Impactados
- [Componente/serviço 1]
- [Componente/serviço 2]

### Mudanças Necessárias
1. [Mudança técnica 1]
2. [Mudança técnica 2]
3. [Mudança de processo/documentação]

### Esforço Estimado
- **Desenvolvimento**: [X days/sprints]
- **Testing**: [X days]
- **Deployment**: [X days]

---

## 📋 Checklist de Validação

Antes de aprovar este ADR, verificar:
- [ ] Contexto claramente explicado
- [ ] Pelo menos 2-3 alternativas consideradas
- [ ] Trade-offs documentados e aceitos
- [ ] Consequências (positivas e negativas) identificadas
- [ ] Riscos mapeados com planos de mitigação
- [ ] Stakeholders consultados
- [ ] Alinhamento com NFRs do projeto
- [ ] Impacto em custo avaliado
- [ ] Compatibilidade com arquitetura existente verificada

---

## 🔗 Referências

- [Link para requisitos relevantes]
- [Link para diagramas de arquitetura]
- [Documentação técnica de tecnologias escolhidas]
- [Benchmarks ou proofs-of-concept]
- [ADRs relacionados]

---

## 📝 Notas Adicionais

[Qualquer informação adicional relevante, como limitações conhecidas, planos futuros de revisão, etc.]

💡 Exemplos de ADRs

Exemplo 1: ADR-001 - Escolha de Database

# ADR-001: Uso de PostgreSQL como Database Principal

**Status**: Aceito  
**Data**: 2025-01-15  
**Autor(es)**: Wilson Santos (Arquiteto)  
**Stakeholders**: Time de Backend, Time de DevOps  
**Decisor**: Wilson Santos

---

## 📌 Contexto

O sistema de gerenciamento de pedidos precisa de um banco de dados relacional para armazenar:
- Cadastro de clientes e produtos
- Histórico de pedidos e transações
- Relacionamentos complexos entre entidades

**Fatores contextuais**:
- Volume esperado: 1M de transações/mês
- Necessidade de ACID compliance
- Time já tem experiência com SQL
- Budget limitado (preferência por open-source)

---

## 🎯 Decisão

**Decisão**: Utilizaremos PostgreSQL 15+ como database principal do sistema.

Implementaremos PostgreSQL com:
- Connection pooling (PgBouncer)
- Read replicas para queries de leitura intensiva
- Backup automatizado diário
- Partitioning para tabelas de histórico

---

## 🔍 Alternativas Consideradas

### Opção 1: MySQL 8.0
**Prós**:
- ✅ Time tem mais experiência
- ✅ Comunidade maior

**Contras**:
- ❌ JSON support inferior ao PostgreSQL
- ❌ Window functions menos robustas

---

### Opção 2: SQL Server
**Prós**:
- ✅ Integração nativa com stack Microsoft
- ✅ Ferramentas empresariais robustas

**Contras**:
- ❌ Custo de licenciamento alto
- ❌ Lock-in com Microsoft

---

### Opção 3: PostgreSQL (Escolhida)
**Prós**:
- ✅ Open-source (zero custo de licença)
- ✅ JSON/JSONB support excelente
- ✅ Window functions completas
- ✅ Extensões (PostGIS, pg_stat_statements)

**Contras**:
- ❌ Curva de aprendizado para alguns membros do time
- ❌ Menos ferramentas GUI comparado a MySQL

---

## 💡 Justificativa

PostgreSQL foi escolhido por:
1. **Custo**: Open-source elimina licenciamento
2. **Features**: JSON support será crítico para integração com APIs externas
3. **Performance**: Benchmarks mostraram 20% melhor performance em queries complexas
4. **Comunidade**: Ativa e em crescimento, com bom suporte

---

## 📊 Consequências

### Positivas
- ✅ Economia de $15k/ano em licenças
- ✅ Flexibilidade com JSON data
- ✅ Performance otimizada para analytics

### Negativas (Trade-offs Aceitos)
- ⚠️ 2 membros do time precisarão de 1 semana de treinamento

### Riscos
- 🚨 **Expertise inicial limitada**: Mitigado com treinamento e documentação interna

Exemplo 2: ADR-002 - Microservices vs Monolith

# ADR-002: Arquitetura Monolítica Modular para MVP

**Status**: Aceito  
**Data**: 2025-02-01  
**Decisão**: Iniciaremos com monolito modular, com plano de evolução para microservices.

**Justificativa**:
- Time pequeno (5 devs)
- Time-to-market crítico (4 meses)
- Domínio ainda sendo descoberto
- Infraestrutura de microservices adiciona complexidade desnecessária no MVP

**Plano de Evolução**:
Após 6 meses de produção, reavaliaremos para potencial migração de módulos específicos (pagamentos, notificações) para microservices baseado em:
- Volume de tráfego por módulo
- Necessidade de escala independente
- Maturidade do domínio

✅ Boas Práticas

Numeração

Use numeração sequencial: ADR-001, ADR-002, etc.
Mantenha registro em docs/adr/ no repositório
Crie índice em docs/adr/README.md

Escrita

✅ Seja conciso mas completo
✅ Use linguagem objetiva (evite jargão excessivo)
✅ Documente o CONTEXTO (não só a decisão)
✅ Sempre liste alternativas consideradas
✅ Seja honesto sobre trade-offs

Processo

✅ ADRs são imutáveis - não delete ou edite após aprovação
✅ Se decisão mudar, crie novo ADR e marque o antigo como "Substituído por ADR-XXX"
✅ Revise ADRs em arquiteture review meetings
✅ Use pull requests para revisar ADRs antes de aprovar

🔗 Integração com Outros Artefatos

{{AVANADE_ARCHITECTURE_TEMPLATE}}: ADRs detalham decisões mencionadas na arquitetura
{{AVANADE_MEMORY_ARCHITECT_WILSON}}: ADRs alimentam a memória com decisões históricas
{{AVANADE_TASK_ARCHITECTURE_QUALITY}}: ADRs são validados com este checklist

📚 Referências

--- --- > **⚠️ [Nome do Cliente] - CONTEXTO OBRIGATÓRIO** > Antes de executar, ler: `[Projeto]-knowledge-base.md`, `[Projeto]-discovery.md`, `especificacao-simulador-notion.md`, `d365-config.yaml` em `.avanade-method/docs/` e `.avanade-method/configs/`. Projeto: D365 CE + Power Pages + Azure Functions + TOTVS/Datasul. ## 📋 O que é este Artefato? Este template fornece uma estrutura padronizada para documentar decisões arquiteturais importantes. ADRs são documentos imutáveis que registram: - **O que** foi decidido - **Por que** essa decisão foi tomada - **Quando** a decisão foi feita - **Quais alternativas** foram consideradas - **Quais trade-offs** foram aceitos --- ## 🎯 Quando Usar Use este template quando: - ✅ Tomar uma decisão arquitetural significativa (tecnologia, padrão, infraestrutura) - ✅ Escolher entre múltiplas opções técnicas com trade-offs claros - ✅ Definir padrões que impactam múltiplos componentes/times - ✅ Documentar escolhas que afetam NFRs (performance, segurança, escalabilidade) - ✅ Reverter ou substituir uma decisão arquitetural anterior **Não use** para decisões triviais ou de implementação de baixo nível. --- ## 📖 Estrutura do Template ### ADR-[NÚMERO]: [TÍTULO DA DECISÃO] ```markdown # ADR-[NÚMERO]: [Título Conciso da Decisão] **Status**: [Proposto | Aceito | Rejeitado | Depreciado | Substituído por ADR-XXX] **Data**: YYYY-MM-DD **Autor(es)**: [Nome(s) do(s) Arquiteto(s)] **Stakeholders**: [Times/pessoas impactados] **Decisor**: [Quem aprovou] --- ## 📌 Contexto [Descreva o contexto que motivou esta decisão. O que está acontecendo? Por que precisamos decidir agora?] **Fatores contextuais**: - Requisitos de negócio relevantes - Constraints técnicos existentes - Deadlines ou dependências - Estado atual da arquitetura --- ## 🎯 Decisão **Decisão**: [Uma frase clara do que foi decidido] [Descreva a decisão em detalhes: o que será implementado, como funcionará, quais tecnologias/padrões serão usados] --- ## 🔍 Alternativas Consideradas ### Opção 1: [Nome da Opção] **Descrição**: [Como funcionaria] **Prós**: - ✅ [Vantagem 1] - ✅ [Vantagem 2] **Contras**: - ❌ [Desvantagem 1] - ❌ [Desvantagem 2] --- ### Opção 2: [Nome da Opção] **Descrição**: [Como funcionaria] **Prós**: - ✅ [Vantagem 1] - ✅ [Vantagem 2] **Contras**: - ❌ [Desvantagem 1] - ❌ [Desvantagem 2] --- ### Opção 3: [Nome da Opção] (Escolhida) **Descrição**: [Como funcionaria] **Prós**: - ✅ [Vantagem 1] - ✅ [Vantagem 2] **Contras**: - ❌ [Desvantagem 1] - ❌ [Desvantagem 2] --- ## ⚖️ Análise de Trade-offs | Critério | Opção 1 | Opção 2 | Opção 3 (Escolhida) | |----------|---------|---------|---------------------| | Performance | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | | Scalability | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | | Cost | 💰💰💰 | 💰 | 💰💰 | | Complexity | 🔧🔧 | 🔧🔧🔧🔧 | 🔧🔧🔧 | | Time to Market | 🚀🚀 | 🚀🚀🚀🚀 | 🚀🚀🚀 | | Maintainability | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | --- ## 💡 Justificativa [Explique POR QUE a opção escolhida é a melhor dado o contexto. Quais fatores foram mais importantes?] **Fatores decisivos**: 1. [Razão principal #1] 2. [Razão principal #2] 3. [Razão principal #3] --- ## 📊 Consequências ### Positivas - ✅ [Benefício esperado 1] - ✅ [Benefício esperado 2] - ✅ [Benefício esperado 3] ### Negativas (Trade-offs Aceitos) - ⚠️ [Trade-off 1 - como mitigar] - ⚠️ [Trade-off 2 - como mitigar] ### Riscos - 🚨 **[Risco 1]**: [Como mitigar] - 🚨 **[Risco 2]**: [Como mitigar] --- ## 🏗️ Implementação ### Componentes Impactados - [Componente/serviço 1] - [Componente/serviço 2] ### Mudanças Necessárias 1. [Mudança técnica 1] 2. [Mudança técnica 2] 3. [Mudança de processo/documentação] ### Esforço Estimado - **Desenvolvimento**: [X days/sprints] - **Testing**: [X days] - **Deployment**: [X days] --- ## 📋 Checklist de Validação Antes de aprovar este ADR, verificar: - [ ] Contexto claramente explicado - [ ] Pelo menos 2-3 alternativas consideradas - [ ] Trade-offs documentados e aceitos - [ ] Consequências (positivas e negativas) identificadas - [ ] Riscos mapeados com planos de mitigação - [ ] Stakeholders consultados - [ ] Alinhamento com NFRs do projeto - [ ] Impacto em custo avaliado - [ ] Compatibilidade com arquitetura existente verificada --- ## 🔗 Referências - [Link para requisitos relevantes] - [Link para diagramas de arquitetura] - [Documentação técnica de tecnologias escolhidas] - [Benchmarks ou proofs-of-concept] - [ADRs relacionados] --- ## 📝 Notas Adicionais [Qualquer informação adicional relevante, como limitações conhecidas, planos futuros de revisão, etc.] ``` --- ## 💡 Exemplos de ADRs ### Exemplo 1: ADR-001 - Escolha de Database ```markdown # ADR-001: Uso de PostgreSQL como Database Principal **Status**: Aceito **Data**: 2025-01-15 **Autor(es)**: Wilson Santos (Arquiteto) **Stakeholders**: Time de Backend, Time de DevOps **Decisor**: Wilson Santos --- ## 📌 Contexto O sistema de gerenciamento de pedidos precisa de um banco de dados relacional para armazenar: - Cadastro de clientes e produtos - Histórico de pedidos e transações - Relacionamentos complexos entre entidades **Fatores contextuais**: - Volume esperado: 1M de transações/mês - Necessidade de ACID compliance - Time já tem experiência com SQL - Budget limitado (preferência por open-source) --- ## 🎯 Decisão **Decisão**: Utilizaremos PostgreSQL 15+ como database principal do sistema. Implementaremos PostgreSQL com: - Connection pooling (PgBouncer) - Read replicas para queries de leitura intensiva - Backup automatizado diário - Partitioning para tabelas de histórico --- ## 🔍 Alternativas Consideradas ### Opção 1: MySQL 8.0 **Prós**: - ✅ Time tem mais experiência - ✅ Comunidade maior **Contras**: - ❌ JSON support inferior ao PostgreSQL - ❌ Window functions menos robustas --- ### Opção 2: SQL Server **Prós**: - ✅ Integração nativa com stack Microsoft - ✅ Ferramentas empresariais robustas **Contras**: - ❌ Custo de licenciamento alto - ❌ Lock-in com Microsoft --- ### Opção 3: PostgreSQL (Escolhida) **Prós**: - ✅ Open-source (zero custo de licença) - ✅ JSON/JSONB support excelente - ✅ Window functions completas - ✅ Extensões (PostGIS, pg_stat_statements) **Contras**: - ❌ Curva de aprendizado para alguns membros do time - ❌ Menos ferramentas GUI comparado a MySQL --- ## 💡 Justificativa PostgreSQL foi escolhido por: 1. **Custo**: Open-source elimina licenciamento 2. **Features**: JSON support será crítico para integração com APIs externas 3. **Performance**: Benchmarks mostraram 20% melhor performance em queries complexas 4. **Comunidade**: Ativa e em crescimento, com bom suporte --- ## 📊 Consequências ### Positivas - ✅ Economia de $15k/ano em licenças - ✅ Flexibilidade com JSON data - ✅ Performance otimizada para analytics ### Negativas (Trade-offs Aceitos) - ⚠️ 2 membros do time precisarão de 1 semana de treinamento ### Riscos - 🚨 **Expertise inicial limitada**: Mitigado com treinamento e documentação interna ``` --- ### Exemplo 2: ADR-002 - Microservices vs Monolith ```markdown # ADR-002: Arquitetura Monolítica Modular para MVP **Status**: Aceito **Data**: 2025-02-01 **Decisão**: Iniciaremos com monolito modular, com plano de evolução para microservices. **Justificativa**: - Time pequeno (5 devs) - Time-to-market crítico (4 meses) - Domínio ainda sendo descoberto - Infraestrutura de microservices adiciona complexidade desnecessária no MVP **Plano de Evolução**: Após 6 meses de produção, reavaliaremos para potencial migração de módulos específicos (pagamentos, notificações) para microservices baseado em: - Volume de tráfego por módulo - Necessidade de escala independente - Maturidade do domínio ``` --- ## ✅ Boas Práticas ### Numeração - Use numeração sequencial: ADR-001, ADR-002, etc. - Mantenha registro em `docs/adr/` no repositório - Crie índice em `docs/adr/README.md` ### Escrita - ✅ Seja conciso mas completo - ✅ Use linguagem objetiva (evite jargão excessivo) - ✅ Documente o CONTEXTO (não só a decisão) - ✅ Sempre liste alternativas consideradas - ✅ Seja honesto sobre trade-offs ### Processo - ✅ ADRs são **imutáveis** - não delete ou edite após aprovação - ✅ Se decisão mudar, crie novo ADR e marque o antigo como "Substituído por ADR-XXX" - ✅ Revise ADRs em arquiteture review meetings - ✅ Use pull requests para revisar ADRs antes de aprovar --- ## 🔗 Integração com Outros Artefatos - **{{AVANADE_ARCHITECTURE_TEMPLATE}}**: ADRs detalham decisões mencionadas na arquitetura - **{{AVANADE_MEMORY_ARCHITECT_WILSON}}**: ADRs alimentam a memória com decisões históricas - **{{AVANADE_TASK_ARCHITECTURE_QUALITY}}**: ADRs são validados com este checklist --- ## 📚 Referências - [Documenting Architecture Decisions - Michael Nygard](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) - [ADR GitHub Organization](https://adr.github.io/) - [When to Use ADRs](https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records) ---

{ "prompt": "---\n---\n\n> **⚠️ [Nome do Cliente] - CONTEXTO OBRIGATÓRIO**\n> Antes de executar, ler: `[Projeto]-knowledge-base.md`, `[Projeto]-discovery.md`, `especificacao-simulador-notion.md`, `d365-config.yaml` em `.avanade-method/docs/` e `.avanade-method/configs/`. Projeto: D365 CE + Power Pages + Azure Functions + TOTVS/Datasul.\n\n## 📋 O que é este Artefato?\n\nEste template fornece uma estrutura padronizada para documentar decisões arquiteturais importantes. ADRs são documentos imutáveis que registram:\n- **O que** foi decidido\n- **Por que** essa decisão foi tomada\n- **Quando** a decisão foi feita\n- **Quais alternativas** foram consideradas\n- **Quais trade-offs** foram aceitos\n\n---\n\n## 🎯 Quando Usar\n\nUse este template quando:\n- ✅ Tomar uma decisão arquitetural significativa (tecnologia, padrão, infraestrutura)\n- ✅ Escolher entre múltiplas opções técnicas com trade-offs claros\n- ✅ Definir padrões que impactam múltiplos componentes/times\n- ✅ Documentar escolhas que afetam NFRs (performance, segurança, escalabilidade)\n- ✅ Reverter ou substituir uma decisão arquitetural anterior\n\n**Não use** para decisões triviais ou de implementação de baixo nível.\n\n---\n\n## 📖 Estrutura do Template\n\n### ADR-[NÚMERO]: [TÍTULO DA DECISÃO]\n\n```markdown\n# ADR-[NÚMERO]: [Título Conciso da Decisão]\n\n**Status**: [Proposto | Aceito | Rejeitado | Depreciado | Substituído por ADR-XXX] \n**Data**: YYYY-MM-DD \n**Autor(es)**: [Nome(s) do(s) Arquiteto(s)] \n**Stakeholders**: [Times/pessoas impactados] \n**Decisor**: [Quem aprovou]\n\n---\n\n## 📌 Contexto\n\n[Descreva o contexto que motivou esta decisão. O que está acontecendo? Por que precisamos decidir agora?]\n\n**Fatores contextuais**:\n- Requisitos de negócio relevantes\n- Constraints técnicos existentes\n- Deadlines ou dependências\n- Estado atual da arquitetura\n\n---\n\n## 🎯 Decisão\n\n**Decisão**: [Uma frase clara do que foi decidido]\n\n[Descreva a decisão em detalhes: o que será implementado, como funcionará, quais tecnologias/padrões serão usados]\n\n---\n\n## 🔍 Alternativas Consideradas\n\n### Opção 1: [Nome da Opção]\n**Descrição**: [Como funcionaria]\n**Prós**:\n- ✅ [Vantagem 1]\n- ✅ [Vantagem 2]\n\n**Contras**:\n- ❌ [Desvantagem 1]\n- ❌ [Desvantagem 2]\n\n---\n\n### Opção 2: [Nome da Opção]\n**Descrição**: [Como funcionaria]\n**Prós**:\n- ✅ [Vantagem 1]\n- ✅ [Vantagem 2]\n\n**Contras**:\n- ❌ [Desvantagem 1]\n- ❌ [Desvantagem 2]\n\n---\n\n### Opção 3: [Nome da Opção] (Escolhida)\n**Descrição**: [Como funcionaria]\n**Prós**:\n- ✅ [Vantagem 1]\n- ✅ [Vantagem 2]\n\n**Contras**:\n- ❌ [Desvantagem 1]\n- ❌ [Desvantagem 2]\n\n---\n\n## ⚖️ Análise de Trade-offs\n\n| Critério | Opção 1 | Opção 2 | Opção 3 (Escolhida) |\n|----------|---------|---------|---------------------|\n| Performance | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |\n| Scalability | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |\n| Cost | 💰💰💰 | 💰 | 💰💰 |\n| Complexity | 🔧🔧 | 🔧🔧🔧🔧 | 🔧🔧🔧 |\n| Time to Market | 🚀🚀 | 🚀🚀🚀🚀 | 🚀🚀🚀 |\n| Maintainability | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |\n\n---\n\n## 💡 Justificativa\n\n[Explique POR QUE a opção escolhida é a melhor dado o contexto. Quais fatores foram mais importantes?]\n\n**Fatores decisivos**:\n1. [Razão principal #1]\n2. [Razão principal #2]\n3. [Razão principal #3]\n\n---\n\n## 📊 Consequências\n\n### Positivas\n- ✅ [Benefício esperado 1]\n- ✅ [Benefício esperado 2]\n- ✅ [Benefício esperado 3]\n\n### Negativas (Trade-offs Aceitos)\n- ⚠️ [Trade-off 1 - como mitigar]\n- ⚠️ [Trade-off 2 - como mitigar]\n\n### Riscos\n- 🚨 **[Risco 1]**: [Como mitigar]\n- 🚨 **[Risco 2]**: [Como mitigar]\n\n---\n\n## 🏗️ Implementação\n\n### Componentes Impactados\n- [Componente/serviço 1]\n- [Componente/serviço 2]\n\n### Mudanças Necessárias\n1. [Mudança técnica 1]\n2. [Mudança técnica 2]\n3. [Mudança de processo/documentação]\n\n### Esforço Estimado\n- **Desenvolvimento**: [X days/sprints]\n- **Testing**: [X days]\n- **Deployment**: [X days]\n\n---\n\n## 📋 Checklist de Validação\n\nAntes de aprovar este ADR, verificar:\n- [ ] Contexto claramente explicado\n- [ ] Pelo menos 2-3 alternativas consideradas\n- [ ] Trade-offs documentados e aceitos\n- [ ] Consequências (positivas e negativas) identificadas\n- [ ] Riscos mapeados com planos de mitigação\n- [ ] Stakeholders consultados\n- [ ] Alinhamento com NFRs do projeto\n- [ ] Impacto em custo avaliado\n- [ ] Compatibilidade com arquitetura existente verificada\n\n---\n\n## 🔗 Referências\n\n- [Link para requisitos relevantes]\n- [Link para diagramas de arquitetura]\n- [Documentação técnica de tecnologias escolhidas]\n- [Benchmarks ou proofs-of-concept]\n- [ADRs relacionados]\n\n---\n\n## 📝 Notas Adicionais\n\n[Qualquer informação adicional relevante, como limitações conhecidas, planos futuros de revisão, etc.]\n```\n\n---\n\n## 💡 Exemplos de ADRs\n\n### Exemplo 1: ADR-001 - Escolha de Database\n\n```markdown\n# ADR-001: Uso de PostgreSQL como Database Principal\n\n**Status**: Aceito \n**Data**: 2025-01-15 \n**Autor(es)**: Wilson Santos (Arquiteto) \n**Stakeholders**: Time de Backend, Time de DevOps \n**Decisor**: Wilson Santos\n\n---\n\n## 📌 Contexto\n\nO sistema de gerenciamento de pedidos precisa de um banco de dados relacional para armazenar:\n- Cadastro de clientes e produtos\n- Histórico de pedidos e transações\n- Relacionamentos complexos entre entidades\n\n**Fatores contextuais**:\n- Volume esperado: 1M de transações/mês\n- Necessidade de ACID compliance\n- Time já tem experiência com SQL\n- Budget limitado (preferência por open-source)\n\n---\n\n## 🎯 Decisão\n\n**Decisão**: Utilizaremos PostgreSQL 15+ como database principal do sistema.\n\nImplementaremos PostgreSQL com:\n- Connection pooling (PgBouncer)\n- Read replicas para queries de leitura intensiva\n- Backup automatizado diário\n- Partitioning para tabelas de histórico\n\n---\n\n## 🔍 Alternativas Consideradas\n\n### Opção 1: MySQL 8.0\n**Prós**:\n- ✅ Time tem mais experiência\n- ✅ Comunidade maior\n\n**Contras**:\n- ❌ JSON support inferior ao PostgreSQL\n- ❌ Window functions menos robustas\n\n---\n\n### Opção 2: SQL Server\n**Prós**:\n- ✅ Integração nativa com stack Microsoft\n- ✅ Ferramentas empresariais robustas\n\n**Contras**:\n- ❌ Custo de licenciamento alto\n- ❌ Lock-in com Microsoft\n\n---\n\n### Opção 3: PostgreSQL (Escolhida)\n**Prós**:\n- ✅ Open-source (zero custo de licença)\n- ✅ JSON/JSONB support excelente\n- ✅ Window functions completas\n- ✅ Extensões (PostGIS, pg_stat_statements)\n\n**Contras**:\n- ❌ Curva de aprendizado para alguns membros do time\n- ❌ Menos ferramentas GUI comparado a MySQL\n\n---\n\n## 💡 Justificativa\n\nPostgreSQL foi escolhido por:\n1. **Custo**: Open-source elimina licenciamento\n2. **Features**: JSON support será crítico para integração com APIs externas\n3. **Performance**: Benchmarks mostraram 20% melhor performance em queries complexas\n4. **Comunidade**: Ativa e em crescimento, com bom suporte\n\n---\n\n## 📊 Consequências\n\n### Positivas\n- ✅ Economia de $15k/ano em licenças\n- ✅ Flexibilidade com JSON data\n- ✅ Performance otimizada para analytics\n\n### Negativas (Trade-offs Aceitos)\n- ⚠️ 2 membros do time precisarão de 1 semana de treinamento\n\n### Riscos\n- 🚨 **Expertise inicial limitada**: Mitigado com treinamento e documentação interna\n```\n\n---\n\n### Exemplo 2: ADR-002 - Microservices vs Monolith\n\n```markdown\n# ADR-002: Arquitetura Monolítica Modular para MVP\n\n**Status**: Aceito \n**Data**: 2025-02-01 \n**Decisão**: Iniciaremos com monolito modular, com plano de evolução para microservices.\n\n**Justificativa**:\n- Time pequeno (5 devs)\n- Time-to-market crítico (4 meses)\n- Domínio ainda sendo descoberto\n- Infraestrutura de microservices adiciona complexidade desnecessária no MVP\n\n**Plano de Evolução**:\nApós 6 meses de produção, reavaliaremos para potencial migração de módulos específicos (pagamentos, notificações) para microservices baseado em:\n- Volume de tráfego por módulo\n- Necessidade de escala independente\n- Maturidade do domínio\n```\n\n---\n\n## ✅ Boas Práticas\n\n### Numeração\n- Use numeração sequencial: ADR-001, ADR-002, etc.\n- Mantenha registro em `docs/adr/` no repositório\n- Crie índice em `docs/adr/README.md`\n\n### Escrita\n- ✅ Seja conciso mas completo\n- ✅ Use linguagem objetiva (evite jargão excessivo)\n- ✅ Documente o CONTEXTO (não só a decisão)\n- ✅ Sempre liste alternativas consideradas\n- ✅ Seja honesto sobre trade-offs\n\n### Processo\n- ✅ ADRs são **imutáveis** - não delete ou edite após aprovação\n- ✅ Se decisão mudar, crie novo ADR e marque o antigo como \"Substituído por ADR-XXX\"\n- ✅ Revise ADRs em arquiteture review meetings\n- ✅ Use pull requests para revisar ADRs antes de aprovar\n\n---\n\n## 🔗 Integração com Outros Artefatos\n\n- **{{AVANADE_ARCHITECTURE_TEMPLATE}}**: ADRs detalham decisões mencionadas na arquitetura\n- **{{AVANADE_MEMORY_ARCHITECT_WILSON}}**: ADRs alimentam a memória com decisões históricas\n- **{{AVANADE_TASK_ARCHITECTURE_QUALITY}}**: ADRs são validados com este checklist\n\n---\n\n## 📚 Referências\n\n- [Documenting Architecture Decisions - Michael Nygard](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)\n- [ADR GitHub Organization](https://adr.github.io/)\n- [When to Use ADRs](https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records)\n\n---", "variables": [ "AVANADE_ARCHITECTURE_TEMPLATE", "AVANADE_MEMORY_ARCHITECT_WILSON", "AVANADE_TASK_ARCHITECTURE_QUALITY" ], "notes": "--- ---", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/ricardobalbino/code-dynamics", "path": ".github/prompts/adr-template.prompt.md", "ref": "44df305621106dc352360645721c53d942aaa178", "url": "https://github.com/ricardobalbino/code-dynamics/blob/44df305621106dc352360645721c53d942aaa178/.github/prompts/adr-template.prompt.md", "key": "ricardobalbino/code-dynamics/.github/prompts/adr-template.prompt.md" } } }

adr-template

About

---

📋 O que é este Artefato?

🎯 Quando Usar

📖 Estrutura do Template

ADR-[NÚMERO]: [TÍTULO DA DECISÃO]

💡 Exemplos de ADRs

Exemplo 1: ADR-001 - Escolha de Database

Exemplo 2: ADR-002 - Microservices vs Monolith

✅ Boas Práticas

Numeração

Escrita

Processo

🔗 Integração com Outros Artefatos

📚 Referências

Use it

Manifest

Reviews

About

﻿---

📋 O que é este Artefato?

🎯 Quando Usar

📖 Estrutura do Template

ADR-[NÚMERO]: [TÍTULO DA DECISÃO]

💡 Exemplos de ADRs

Exemplo 1: ADR-001 - Escolha de Database

Exemplo 2: ADR-002 - Microservices vs Monolith

✅ Boas Práticas

Numeração

Escrita

Processo

🔗 Integração com Outros Artefatos

📚 Referências

Use it

Manifest

Reviews

---