Recursos

Templates y Checklists

Plantillas listas para usar en tus proyectos de arquitectura de software.

📄 Architecture Decision Record (ADR)

Documento para registrar decisiones arquitectónicas importantes. Guardalo como docs/adr/NNN-titulo.md en tu repositorio.

# ADR-NNN: [Título de la decisión]

## Estado
Propuesto | Aceptado | Deprecado | Reemplazado por ADR-XXX

## Contexto
Describí el problema o la necesidad que motivó esta decisión.
¿Qué fuerzas están en juego? ¿Qué restricciones existen?

## Decisión
Describí la decisión tomada de forma clara y concisa.
"Vamos a usar [tecnología/patrón/enfoque] para [objetivo]."

## Consecuencias

### Positivas
- Beneficio 1
- Beneficio 2

### Negativas
- Trade-off 1
- Trade-off 2

### Riesgos
- Riesgo identificado y mitigación propuesta

## Alternativas Consideradas

### Alternativa A: [Nombre]
- Pros: ...
- Contras: ...
- Razón de descarte: ...

### Alternativa B: [Nombre]
- Pros: ...
- Contras: ...
- Razón de descarte: ...

## Referencias
- Links a documentación, RFCs, artículos relevantes

✅ Checklist de Revisión Arquitectónica

Usá esta checklist antes de aprobar cambios arquitectónicos significativos.

# Checklist de Revisión Arquitectónica

## Diseño General
- [ ] ¿La solución resuelve el problema planteado?
- [ ] ¿Se consideraron al menos 2 alternativas?
- [ ] ¿Los trade-offs están documentados?
- [ ] ¿La complejidad es proporcional al problema?

## Escalabilidad
- [ ] ¿Cómo escala con 10x usuarios?
- [ ] ¿Hay cuellos de botella identificados?
- [ ] ¿Se puede escalar horizontalmente?

## Resiliencia
- [ ] ¿Qué pasa si un servicio externo falla?
- [ ] ¿Hay timeouts configurados?
- [ ] ¿Existen circuit breakers donde corresponde?
- [ ] ¿Las operaciones críticas son idempotentes?

## Seguridad
- [ ] ¿La autenticación y autorización están implementadas?
- [ ] ¿Los datos sensibles están encriptados?
- [ ] ¿Se validan todos los inputs?
- [ ] ¿Los secretos están en un vault, no en código?

## Observabilidad
- [ ] ¿Hay logging estructurado?
- [ ] ¿Las métricas clave están instrumentadas?
- [ ] ¿Existe tracing distribuido?
- [ ] ¿Hay alertas configuradas?

## Operaciones
- [ ] ¿El deploy es automatizado?
- [ ] ¿Se puede hacer rollback rápido?
- [ ] ¿La configuración está externalizada?
- [ ] ¿Hay health checks implementados?

## Datos
- [ ] ¿El esquema de datos soporta la evolución?
- [ ] ¿Hay estrategia de migración?
- [ ] ¿Los backups están configurados?
- [ ] ¿La consistencia de datos es adecuada?

📝 Propuesta Técnica (RFC)

Template para proponer cambios técnicos significativos al equipo.

# RFC: [Título de la propuesta]

## Resumen
Una o dos oraciones que describan la propuesta.

## Motivación
¿Por qué es necesario este cambio? ¿Qué problema resuelve?
Incluí métricas o datos que soporten la necesidad.

## Propuesta Detallada

### Arquitectura
Describí los componentes involucrados y cómo interactúan.

### API / Interfaces
Definí los contratos entre componentes.

### Modelo de Datos
Describí los cambios en el esquema de datos.

### Migración
¿Cómo se migra del estado actual al propuesto?

## Plan de Implementación
1. Fase 1: ...
2. Fase 2: ...
3. Fase 3: ...

## Métricas de Éxito
¿Cómo sabemos que la propuesta fue exitosa?

## Riesgos y Mitigaciones
| Riesgo | Probabilidad | Impacto | Mitigación |
|--------|-------------|---------|------------|
| ...    | Alta/Media/Baja | Alto/Medio/Bajo | ... |

## Timeline Estimado
- Diseño: X semanas
- Implementación: X semanas
- Testing: X semanas
- Rollout: X semanas

🔍 Post-Mortem de Incidentes

Template para documentar y aprender de incidentes en producción.

# Post-Mortem: [Título del incidente]

## Resumen
- Fecha: YYYY-MM-DD
- Duración: X horas/minutos
- Impacto: Descripción del impacto en usuarios/negocio
- Severidad: P1/P2/P3/P4

## Timeline
| Hora  | Evento |
|-------|--------|
| HH:MM | Se detectó el problema |
| HH:MM | Se notificó al equipo |
| HH:MM | Se identificó la causa raíz |
| HH:MM | Se aplicó el fix |
| HH:MM | Se confirmó la resolución |

## Causa Raíz
Descripción técnica de qué causó el incidente.

## Qué Salió Bien
- Las alertas detectaron el problema en X minutos
- El equipo respondió rápidamente

## Qué Salió Mal
- No había runbook para este escenario
- El rollback tardó más de lo esperado

## Action Items
| Acción | Responsable | Fecha límite | Estado |
|--------|------------|-------------|--------|
| ...    | ...        | YYYY-MM-DD  | Pendiente |

## Lecciones Aprendidas
Reflexiones del equipo sobre cómo prevenir incidentes similares.