Decisiones arquitectónicas

ADR-001 — Screaming Architecture en el frontend

Decisión: Organizar los módulos Angular por dominio de negocio (auth, portal, settings, azure, vmware, etc.) en lugar de por tipo técnico.
Motivo: Facilita la localización del código relevante a una funcionalidad sin conocimiento previo del framework. Mejora el onboarding y reduce el acoplamiento entre dominios.

ADR-002 — Microservicios por responsabilidad en el backend

Decisión: Separar el backend en microservicios independientes (authentication, authorization, clients, integrations, logs, reports, orphans, images).
Motivo: Permite escalar, desplegar y mantener cada responsabilidad de forma independiente. Reduce el impacto de fallos al aislar servicios críticos.

ADR-003 — Nginx como API Gateway

Decisión: Un único Nginx actúa como reverse proxy, enrutando peticiones a los microservicios por prefijo de URL.
Motivo: Punto de entrada unificado simplifica la configuración de CORS, TLS y enrutamiento. Permite servir también archivos estáticos (imágenes, fotos de perfil) sin un servicio adicional.

ADR-004 — Redis para caché de datos Zabbix

Decisión: Un worker dedicado (zabbix-cache-updater) sincroniza datos de Zabbix en Redis cada 120 segundos.
Motivo: La API de Zabbix puede ser lenta bajo carga. Desacoplar la actualización de la consulta permite respuestas sub-segundo para alertas e inventario sin sobrecargar Zabbix.

ADR-005 — Theming dinámico por OpCo vía CSS Custom Properties

Decisión: El ThemeService sobreescribe --mat-sys-primary en tiempo de ejecución según la OpCo del usuario autenticado.
Motivo: Un único build de la aplicación sirve a todas las OpCos. El tema se aplica en tiempo de ejecución sin necesidad de builds separados por marca.

ADR-006 — HashLocationStrategy en Angular

Decisión: La SPA usa routing basado en hash (/#/portal/home).
Motivo: Simplifica el despliegue en Nginx sin necesidad de configurar try_files para el manejo de rutas HTML5. Compatible con la configuración actual de Nginx que sirve el frontend.

ADR-007 — Componentes Standalone en Angular

Decisión: Se usa la arquitectura de componentes standalone (sin NgModule explícitos).
Motivo: Reduce el boilerplate, mejora el tree-shaking y sigue las recomendaciones de Angular 17+ para proyectos nuevos.

ADR-008 — APScheduler para reportes programados

Decisión: El servicio reports usa APScheduler embebido para ejecutar tareas cron (reporte mensual 0 0 1 * *, tarea diaria 0 0 * * *).
Motivo: Evita la dependencia de un orquestador externo (Celery, Airflow) para tareas simples y periódicas, manteniendo la arquitectura autocontenida.