Module Base – Requerimientos

Resumen: librería base para módulos del navegador que provee contratos, clases/servicios mínimos y auto‑registro, con configuración directa por módulo e integración con multitenancy/seguridad.

Alcance e ítems fuera de alcance

En alcance

• R-001: Contratos base de módulo (BrowserModuleContract, ModuleManifest) y ciclo de vida.
• R-002: Decorador @ModuleDecorator con auto‑registro y manifest.
• R-003: Configuración directa via configure(config) sin tokens de DI.
• R-004: Servicios centrales: ModuleRegistry, ModuleDiscovery, ModuleConfiguration/ModuleConfig.
• R-005: Integración con @libs-core/security (tenant context/permisos) y con @libs-core/event-system y @libs-core/log-system.
• R-006: Estado y acciones base (signals/NGXS opcional), Action Registry.
• R-007: Componentes base standalone (BaseModuleComponent, ModuleLayout, ModuleRouterOutlet, ComponentBase).
• R-008: Eventos de ciclo de vida y observabilidad (logging + event bus).

Fuera de alcance

• Implementaciones de módulos de negocio finales.
• Module Federation y tokens de configuración específicos de Angular.
• UI compleja más allá de componentes base y layout mínimo.

Suposiciones y restricciones

• Angular 20+, standalone components, signals; sin Module Federation.
• Multitenancy y API base se resuelven exclusivamente vía @libs-core/security.
• KISS y tree‑shaking: API mínima, sin factories complejas ni tokens.
• Compatibilidad: navegadores modernos; RxJS 7.8+; NGXS opcional.

Stakeholders/roles

• Arquitectura FE, Desarrolladores de módulos, QA, DevOps/Platform.

Historias de usuario (US)

• US-001 – Auto‑registro y contrato simple

  • Como desarrollador de módulos quiero implementar un contrato simple y auto‑registrar mi módulo para evitar wiring manual.
  • Criterios (AC-001):
    • Un módulo con @ModuleDecorator({id, version}) aparece en el ModuleRegistry al iniciar.
    • manifest expone id y versión; no requiere tokens para configurarse.
  • Reqs: R-001, R-002, R-003, R-004.
  • Prioridad: Alta.

• US-002 – Configuración por tenant desde API

  • Como integrador quiero configurar/activar módulos por tenant para habilitar features y permisos.
  • Criterios (AC-002):
    • ModuleConfigurationService entrega configuración por moduleId considerando tenant actual.
    • Si enabled=true, el módulo entra a ciclo de vida; se valida permiso con security.
  • Reqs: R-004, R-005, R-008.
  • Prioridad: Alta.

• US-003 – Acciones y estado base interoperables

  • Como desarrollador de plataforma quiero exponer acciones y estado base para compartir comportamientos entre módulos.
  • Criterios (AC-003):
    • Existe ModuleStateService y selectores base; integra signals y NGXS opcional.
    • Acciones registrables mediante Action Registry.
  • Reqs: R-006, R-008.
  • Prioridad: Media.

Requerimientos no funcionales (NFR)

• NFR-01 Performance: bundle core < 12KB gz; tree‑shaking efectivo.
• NFR-02 Calidad: cobertura ≥ 90% unit y ≥ 85% integración.
• NFR-03 Seguridad: cumplimiento CSP; permisos por módulo desde security.
• NFR-04 Observabilidad: logs y eventos en cada transición de ciclo de vida.
• NFR-05 Compatibilidad: Angular 20, RxJS 7.8+, navegadores modernos.
• NFR-06 Testeabilidad: Deben ejcutarse correctamente el 100% de las pruebas asociadas

Glosario

• Módulo: paquete funcional que implementa BrowserModuleContract.
• Tenant: contexto de cliente actual provisto por @libs-core/security.
• Manifest: metadatos (id, versión) expuestos por el módulo.
• Action Registry: registro/descubrimiento de acciones públicas.