Design Patterns

Este documento detalla los patrones de diseño utilizados en el worker de recolección de logística inversa.

Arquitectura Hexagonal (Puertos y Adaptadores)

• Descripción: La Arquitectura Hexagonal, también conocida como Puertos y Adaptadores, es un patrón arquitectónico que permite que una aplicación sea igualmente impulsada por usuarios, programas, pruebas automatizadas o scripts por lotes, y que se desarrolle y pruebe de forma aislada de sus eventuales dispositivos y bases de datos en tiempo de ejecución.

• Componentes clave:

  1. Componentes principales:
     • Capa de dominio: Contiene la lógica de negocio y entities
     • Capa de aplicación: Contiene casos de uso y orquesta la lógica del dominio
     • Capa de infraestructura: Contiene adaptadores para servicios externos
  2. Implementación en la aplicación:
     • Interfaces del dominio: Definen puertos para servicios externos (por ejemplo, QueueService, ProductService)
     • Implementaciones de infraestructura: Proporcionan adaptadores para servicios externos (por ejemplo, AwsQueueService)
  3. Casos de uso:
     • CollectorProcessor: Utiliza servicios del dominio a través de interfaces, no implementaciones concretas

Inyección de Dependencias

• Descripción: La Inyección de Dependencias es un patrón de diseño donde los objetos reciben sus dependencias de fuentes externas en lugar de crearlas internamente.

• Componentes clave:

  1. Componentes principales:
     • Inyección por constructor: Las dependencias se proporcionan a través de constructores
     • Funciones proveedoras: Funciones de fábrica que crean y conectan dependencias
  2. Implementación en la aplicación:
     • Constructor de CollectorProcessor: Recibe servicios como dependencias
     • Constructor de CollectorWorker: Recibe servicios como dependencias
     • getCollectorWorker(): Función de fábrica que crea y conecta dependencias
  3. Casos de uso:
     • Facilita las pruebas al permitir implementaciones simuladas
     • Desacopla componentes de sus dependencias

Patrón Repository

• Descripción: El Patrón Repository es un patrón de diseño que media entre el dominio y las capas de mapeo de datos, actuando como una colección en memoria de objetos del dominio.

• Componentes clave:

  1. Componentes principales:
     • Interfaces de Repository: Definen métodos para acceso a datos en la capa de dominio
     • Implementaciones de Repository: Proporcionan implementaciones concretas en la capa de infraestructura
  2. Implementación en la aplicación:
     • ReverseLogisticService: Interfaz que define métodos para acceder a datos de logística inversa
     • Implementaciones de infraestructura de estas interfaces
  3. Casos de uso:
     • Abstrae la lógica de acceso a datos de la lógica de negocio
     • Permite diferentes fuentes de datos sin cambiar la lógica del dominio

Either Monad

• Descripción: Either Monad es un patrón de programación funcional utilizado para el manejo de errores. Representa un valor de uno de dos tipos posibles: un valor de éxito (Right) o un valor de error (Left).

• Componentes clave:

  1. Componentes principales:
     • Either<L, R>: Un tipo que puede ser Left (error) o Right (éxito)
     • EitherAsync<L, R>: Una versión asíncrona de Either
  2. Implementación en la aplicación:
     • @justomx/either: Biblioteca que proporciona implementaciones de Either y EitherAsync
     • Utilizado en toda la aplicación para manejo de errores
  3. Casos de uso:
     • CollectorProcessor.process(): Retorna Either<BusinessError, string>
     • AwsQueueService.receiveMessage(): Retorna Either<BusinessError, PairOfReceiptAndMessage[]>
     • Proporciona una forma consistente de manejar errores sin lanzar excepciones

Factory Pattern

• Descripción: El Factory Pattern es un patrón creacional que proporciona una interfaz para crear objetos sin especificar sus clases concretas.

• Componentes clave:

  1. Componentes principales:
     • Funciones de fábrica: Funciones que crean y retornan objetos
  2. Implementación en la aplicación:
     • getCollectorWorker(): Crea y retorna un CollectorWorker configurado
     • getLogger(): Crea y retorna un logger configurado
  3. Casos de uso:
     • Centraliza la lógica de creación de objetos
     • Simplifica la creación de objetos con dependencias complejas