Skip to main content

Diseño de Alto Nivel (HLD): Plataforma Recomóvil

Versión: 1.0 Autor: Javier Hernández Barraza

1. Introducción y Objetivos​

1.1. Propósito​

Este documento describe la arquitectura de alto nivel para la modernización de la aplicación Recomóvil. El objetivo es migrar de la actual plataforma monolítica basada en BPEL a una arquitectura distribuida, nativa de la nube y basada en microservicios, para mejorar la agilidad, escalabilidad, resiliencia y mantenibilidad del sistema.

1.2. Objetivos de la Arquitectura​

  • Desacoplamiento: Descomponer el monolito en servicios autónomos alineados con los dominios de negocio (DDD).
  • Escalabilidad: Permitir que cada servicio escale de forma independiente según su carga.
  • Resiliencia: Aislar los fallos para que un error en un componente no afecte a todo el sistema.
  • Agilidad de Desarrollo: Facilitar que equipos pequeños trabajen de forma independiente en cada servicio, acelerando el ciclo de vida de desarrollo.
  • Integración Moderna: Exponer funcionalidades a través de APIs RESTful seguras y estandarizadas, y manejar las integraciones con sistemas legacy de forma controlada.

2. Visión General de la Arquitectura​

La arquitectura propuesta es un sistema distribuido compuesto por microservicios de grano fino, un API Manager como punto de entrada único, un proveedor de identidad centralizado y un bus de eventos para la comunicación asíncrona. Las integraciones con sistemas externos (OTM, AS/400) se realizan a través de adaptadores específicos que protegen el núcleo del dominio.

3. Componentes del Sistema (Microservicios)​

Cada microservicio es una unidad de despliegue autónoma, con su propio dominio, lógica de aplicación y base de datos (patrón Database-per-Service).

info

La librería de seguridad estandarizada de alpura realiza la implementación de manera nativa en cada microservicio. Ver Librería seguridad.

  • Servicio de Identidad y Acceso (menu)

    • Responsabilidad: Gestionar la autenticación de usuarios y la emisión de tokens de acceso (JWT). Se integra con el proveedor OIDC corporativo (Keycloak) y se encuentra integrado dentro de la librería de seguridad estadandar.
    • Tecnología: Spring Boot, Spring Security.

  • Servicio de Datos Maestros (maestros-api)

    • Responsabilidad: Servir como fuente de la verdad para datos de referencia como Rutas, Zonas, Orígenes, etc.
    • Tecnología: Spring Boot, JPA/Hibernate, PostgreSQL, Cache (Redis/Caffeine).

  • Servicio de Gestión de Viajes (viajes-api)

    • Responsabilidad: Orquestar el ciclo de vida completo de los viajes de recolección. Es un dominio "Core". Implementa lógica de negocio compleja.
    • Tecnología: Spring Boot, JPA/Hibernate, PostgreSQL, Kafka (para eventos de dominio).

  • Servicio de Control de Acceso (tickets-api)

    • Responsabilidad: Gestionar el proceso de llegada, registro y evaluación de vehículos en planta. Dominio "Core" para el rol de Vigilancia.
    • Tecnología: Spring Boot, JPA/Hibernate, PostgreSQL.

  • Servicio de Auditoría (auditoria-api)

    • Responsabilidad: Orquestar procesos de negocio de larga duración que involucran sistemas legacy, como la sincronización con SIRLA. Implementa el patrón Saga.
    • Tecnología: Spring Boot, JPA/Hibernate, PostgreSQL, Kafka, Adaptadores de integración (ACL).

4. Decisiones Arquitectónicas y Patrones (Cross-Cutting Concerns)​

  • Seguridad:

    • La autenticación se delega a un proveedor OIDC (Keycloak).
    • Los servicios son "Resource Servers" que validan Tokens JWT (OAuth 2.0) en cada petición.
    • La autorización se basa en roles y scopes definidos en el token.

  • Comunicación:

    • Síncrona: Las interacciones cliente-servidor se realizan vía REST (HTTP) a través del API Manager. La comunicación directa entre servicios se debe evitar.
    • Asíncrona: La comunicación entre servicios para notificar cambios de estado se realiza de forma reactiva a través de un Bus de Eventos (Kafka). Esto desacopla los servicios y aumenta la resiliencia.

  • Gestión de Datos:

    • Se sigue el patrón Database-per-Service. Cada microservicio es dueño de su propio esquema de base de datos para garantizar la autonomía.
    • Se utiliza un enfoque CQRS a nivel de aplicación, donde las APIs de consulta leen de proyecciones optimizadas, mientras que los comandos operan sobre el modelo de dominio transaccional.

  • Observabilidad:

    • Logs: Todos los servicios generarán logs estructurados (JSON) que serán centralizados (ej. Stack EFK/ELK).
    • Métricas: Se expondrán métricas de negocio y de sistema a través de Micrometer para ser recolectadas por Prometheus.
    • Trazas: Se implementará trazado distribuido con OpenTelemetry para seguir una petición a través de múltiples servicios y el bus de eventos.

  • Despliegue:

    • Cada servicio se empaquetará como una imagen de contenedor (Docker).
    • Se recomienda un orquestador de contenedores (Kubernetes) para gestionar el despliegue, escalado y networking.
    • Se establecerá un pipeline de CI/CD por cada servicio.

5. Estrategia de Integración​

  • API Manaher: Actúa como punto de entrada único, simplificando la seguridad, el enrutamiento, el rate limiting y la recolección de métricas. Abstrae a los clientes de la topología interna de los microservicios.

  • Anti-Corruption Layer (ACL): Para las integraciones con sistemas legacy (OTM, AS/400), los servicios viajes-api y auditoria-api implementarán Adaptadores específicos. Estos adaptadores traducirán los modelos y protocolos legacy al lenguaje ubicuo del dominio del microservicio, protegiéndolo de la complejidad externa y facilitando futuras migraciones de dichos sistemas legacy.

6. Plan de Migración​

Se adoptará la estrategia Strangler Fig Pattern, desplegando los nuevos microservicios en paralelo al sistema BPEL existente y redirigiendo gradualmente el tráfico a través del API Manager hasta que el sistema antiguo pueda ser desmantelado de forma segura. Las fases se detallan en el PLAN_DE_TRABAJO.md.