Arquitectura de Software

La arquitectura de software en HERA es una decisión estratégica que impacta escalabilidad, costos y velocidad de entrega. Esta sección define los estándares que todo equipo debe seguir.

Principios Arquitectónicos

Toda decisión de arquitectura dentro del ecosistema HERA debe alinearse con estos principios:

1. Contenedores como Unidad de Despliegue

El contenedor Docker es el contrato entre desarrollo e infraestructura. Todo lo que se despliega en HERA es un contenedor que cumple:

Imagen basada en Golden Images certificadas
Multi-stage build para minimizar superficie de ataque
Usuario non-root en runtime
Healthcheck definido
Variables de entorno para configuración (no archivos hardcodeados)

2. Stateless por Diseño

Las aplicaciones deben ser stateless — todo estado persistente vive fuera del contenedor:

Estado	Dónde vive
Datos transaccionales	Cloud SQL (PostgreSQL / MySQL)
Caché	Memorystore (Redis)
Archivos	Cloud Storage (GCS)
Eventos	Pub/Sub
Sesiones	Redis o JWT stateless

3. API-First

Las interfaces entre servicios se definen antes de la implementación. El contrato OpenAPI/Swagger es un artefacto de primera clase, no documentación generada después.

4. Seguridad por Defecto

Cada decisión de arquitectura debe pasar el filtro de Zero Trust:

Autenticación en cada llamada (no confiar en la red)
Autorización granular (mínimo privilegio)
Cifrado en tránsito (TLS obligatorio)
Secretos en Secret Manager, nunca en código

5. Observabilidad Nativa

Las aplicaciones deben nacer con instrumentación:

Logs estructurados (JSON) con correlation ID
Métricas de negocio y técnicas expuestas
Traces distribuidos para operaciones cross-service

6. Costo-Eficiente

Antes de agregar un servicio o componente, pregunta: ¿es necesario? Cada servicio adicional es un costo operacional. Un monolito modular bien diseñado puede ser más eficiente que 15 microservicios prematuros.

Contenido de esta sección

Documento	Qué cubre
Clasificación de Servicios	4 capas estratégicas, 13 categorías, naming convention, trazabilidad
Patrones de Arquitectura	Microservicios, BFF, Event-Driven, Monolito Modular, API Gateway, CQRS
Estándares de Configuración	Context-Aware Naming de 5 capas, secretos en GCP Secret Manager, 12 reglas mandatorias (R1–R12)
Estándares de Etiquetado	K8s labels, mapeo de `product-manifest.yml`, etiquetas `app.kubernetes.io/*`, trazabilidad por dominio

Proceso de Revisión de Arquitectura

Toda nueva aplicación o cambio arquitectónico significativo debe pasar por una revisión de arquitectura antes de comenzar la implementación:

Paso	Responsable	Entregable
Propuesta de diseño	Developer / Tech Lead	Documento de arquitectura (ADR)
Revisión técnica	Arquitecto + Plataforma	Feedback y ajustes
Validación de seguridad	Security Engineer	Aprobación de modelo de amenazas
Aprobación	Tech Lead + Arquitecto	Go/No-Go