Razonamiento y patrones modelo de datos S4 - JohannPaezU/MISW4501-MediSupply GitHub Wiki

Arquitectura: Disponibilidad y Seguridad

Disponibilidad

Táctica aplicada: Monitor

Qué es y cómo se ve en el diagrama

  • Un componente dedicado (Monitor) que recibe los estados y eventos operativos de los demás servicios a través del Event Emitter (líneas Request Monitor).
  • No interviene en el negocio: observa y registra; su única función es visibilidad y alerta.

Razonamiento sobre las decisiones de arquitectura

  • Observabilidad centralizada: Concentrar en un único componente la recolección de estados reduce la dispersión de métricas y agiliza el diagnóstico.
  • No intrusivo: El Monitor consume desde el Event Emitter sin acoplarse a los flujos síncronos; así no agrega latencia ni se convierte en cuello de botella.
  • Continuidad de información: Al llegarle los eventos por un canal común, se facilita reconstruir el contexto (qué falló, cuándo y en qué dominio) y acortar el tiempo de recuperación.
  • Gobernanza operativa: Un solo punto para generar alertas y tableros facilita acordar umbrales y reglas de notificación a operación.

Seguridad (Confidencialidad)

Táctica aplicada 1: Autenticación (Autenticar actores)

Qué es y cómo se ve en el diagrama

  • Los Users solicitan acceso al Authorization Service, que emite un Authorization Token.
  • El API Gateway valida ese token antes de enrutar cualquier petición a los dominios internos.

Razonamiento sobre las decisiones de arquitectura

  • Control en el perímetro: Verificar identidad en el Gateway evita que tráfico no autenticado alcance servicios internos.
  • Separación de responsabilidades: Mantener Authorization Service independiente del Gateway permite escalar, auditar, rotar claves y cambiar políticas sin tocar el enrutamiento.
  • Política uniforme: Un solo punto de validación garantiza reglas consistentes (expiración, scopes) para todo el ecosistema.

Táctica aplicada 2: Certificación (Certificados digitales entre servicios)

Qué es y cómo se ve en el diagrama

  • El API Gateway solicita/recibe certificados del Certification Service (Certificate Request / certificate).
  • Esos certificados habilitan confianza y cifrado en las comunicaciones internas (p. ej., mTLS o validación mutua entre componentes).

Razonamiento sobre las decisiones de arquitectura

  • Confianza de servicio a servicio: Los certificados permiten autenticar componentes y evitar suplantación dentro de la red interna.
  • Ciclo de vida centralizado: Con un Certification Service se estandariza emisión, renovación y revocación; menos riesgo operativo y menor complejidad en cada dominio.
  • Alineación con el Gateway: Colocar la gestión de certificados cerca del punto de entrada refuerza la postura de seguridad de extremo a extremo (cliente → perímetro → servicios).