Architecture

Este documento describe la arquitectura implementada en el microservicio op-inventory-gateway.

Arquitectura

El op-inventory-gateway sigue una arquitectura hexagonal (también conocida como puertos y adaptadores) con una clara separación de responsabilidades entre las diferentes capas. Esta arquitectura permite al microservicio actuar como un gateway entre las aplicaciones cliente y los diferentes sistemas de gestión de inventario.

Capa de Dominio

La capa de dominio es el núcleo de la aplicación y contiene la lógica de negocio. Esta capa define:

• Interfaces de Servicio: Contratos que definen cómo la aplicación interactúa con sistemas externos
• Errores de Dominio: Tipos de errores personalizados específicos del dominio

Componentes Principales

• inventory/service.ts: Define la interfaz para interactuar con el microservicio Inventory Manager
• inventory-item/service.ts: Define la interfaz para interactuar con el servicio Bodegao Inventory Item
• errors.ts: Contiene definiciones de errores específicos del dominio

Capa de Aplicación

Aunque este microservicio no tiene una capa de aplicación explícita como se ve en aplicaciones más complejas, la lógica de enrutamiento en la capa de infraestructura cumple un propósito similar al orquestar el flujo entre el cliente y los servicios de dominio.

Capa de Infraestructura

La capa de infraestructura proporciona implementaciones concretas de las interfaces definidas en la capa de dominio y maneja las preocupaciones técnicas de la aplicación.

• Capa HTTP: Maneja las peticiones HTTP entrantes y las enruta al servicio apropiado
• Implementaciones de Servicios: Implementaciones concretas de las interfaces de servicio del dominio
• Providers: Métodos factory para crear instancias de servicios
• Middleware: Lógica de procesamiento de peticiones
• Gestión de Contexto: Manejo de información de contexto de peticiones
• Logging y Monitoreo: Infraestructura para logging y monitoreo

Componentes Principales

• http/: Contiene la configuración del servidor Express, middlewares y rutas
  • server.ts: Configuración de la aplicación Express
  • middlewares/proccess-transaction.ts: Middleware principal que enruta las peticiones al servicio apropiado
  • routes/: Definiciones de rutas API
• service/: Implementaciones de servicios
  • inventory/: Implementación del servicio Inventory Manager
  • inventory-item/: Implementación del servicio Bodegao Inventory Item
    • wrapper.ts: Wrapper que enruta peticiones basado en el país
• providers/: Métodos factory para crear instancias de servicios
• logger/: Infraestructura de logging
• apm/: Configuración de Application Performance Monitoring
• context/: Gestión de contexto de peticiones

Flujo de Peticiones

1. Una petición HTTP es recibida por el servidor Express
2. El middleware procesa la petición:
   • El ID de petición es generado o propagado
   • La información de ID de usuario, país y almacén se extrae de los headers
   • Se establece el contexto de la petición
3. El processTransactionMiddleware determina qué servicio backend utilizar:
   • Si el almacén está en la lista de habilitados, la petición se enruta al microservicio Inventory Manager
   • De lo contrario, la petición se enruta al servicio Bodegao Inventory Item
4. El servicio apropiado realiza la petición al sistema backend
5. La respuesta se devuelve al cliente

Esta arquitectura permite al microservicio actuar como una fachada, proporcionando una API unificada mientras enruta las peticiones a diferentes sistemas backend basados en la configuración.