Fase de Planeación

🗺️ Fase de Planeación - Estrategia y Arquitectura

La fase de planeación define la hoja de ruta técnica y arquitectónica para cumplir con los objetivos de la Kata. Se busca una solución escalable, resiliente y fácil de mantener.

Estrategia de Desarrollo

Para garantizar el éxito en la Kata, se adoptó una metodología “Microservices-First”, permitiendo que cada componente del sistema evolucione de forma independiente y se integre mediante contratos claros.

Arquitectura de la Solución

Diagrama de Microservicios (Lógico)

graph TB
    subgraph "Frontend Layer"
        FE[Angular Dashboard]
    end

    subgraph "API Gateway Layer"
        GW[NestJS API Gateway]
    end

    subgraph "Core Services Layer"
        RS[Release Manager]
        RE[Rules Engine]
    end

    subgraph "Integration Layer"
        IS[Integrations Service]
        NS[Notification Service]
    end

    subgraph "Storage & APIs"
        DB[(PostgreSQL)]
        GH[GitHub API]
        EOL[endoflife.date API]
        SMTP[Mailtrap SMTP]
    end

    FE --> GW
    GW --> RS
    RS --> RE
    RE --> IS
    IS --> GH
    RE --> EOL
    RS --> DB
    RS --> NS
    NS --> SMTP

Diseño de Infraestructura (Cloud AWS)

La PoC está diseñada para ser desplegada en AWS utilizando Terraform como motor de IaC, garantizando consistencia en todos los ambientes.

Componente	Servicio AWS	Justificación
Computación	ECS Fargate	Serverless para contenedores, escala según demanda y reduce carga operativa.
Base de Datos	RDS PostgreSQL	Motor robusto con backups automáticos y alta disponibilidad.
Balanceo	Application Load Balancer (ALB)	Enrutamiento inteligente a los microservicios y terminación SSL.
Redes	VPC (Public/Private Subnets)	Aislamiento de base de datos y microservicios para mayor seguridad.
Registro	ECR	Repositorio privado para imágenes Docker de los microservicios.

Modelo de Datos (Esquema Principal)

El sistema utiliza un esquema relacional optimizado para la trazabilidad de los releases:

release_request: Tabla maestra que contiene el estado, versión y metadatos del release.
technology_stack: Relación de frameworks y versiones asociados a cada solicitud.
audit_log: Historial completo de cambios de estado y acciones (Manual vs Auto).
notification_history: Registro de comunicaciones enviadas a los aprobadores.

Plan de Mitigación de Riesgos

Riesgo	Impacto	Mitigación
Indisponibilidad de APIs externas	Alto	Implementación de Resilience Patterns (Retries/Circuit Breaker) e información en caché.
Altas latencias en validación	Medio	Procesamiento asíncrono y comunicación optimizada entre microservicios.
Fallos en el despliegue Cloud	Alto	Uso estricto de Terraform con validación de estados y rollback automático en CI/CD.

[!TIP] La arquitectura desacoplada permite que el motor de reglas (Rules Engine) se actualice sin afectar el registro de solicitudes, facilitando la mejora continua de los criterios de aprobación.