Design Patterns

Este documento detalla los patrones de diseño utilizados en el microservicio de Logística Inversa.

Patrón Observer

El patrón Observer es un patrón de diseño de comportamiento que define una dependencia uno a muchos entre objetos, de modo que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados automáticamente.

Implementación

En el microservicio de Logística Inversa, el patrón Observer se implementa para notificar sobre cambios en los elementos de logística inversa, como cuando se crean, cancelan, completan elementos, o cuando se reportan productos como faltantes, no recogidos o desperdiciados.

Componentes clave:

1. Interfaces en la capa de dominio:

   • Observer<T> (src/domain/observer.ts): Define la interfaz para los observers con un método update.
   • Subject<T> (src/domain/subject.ts): Define la interfaz para los subjects observables con métodos subscribe, unsubscribe y notify.

2. Implementación en la capa de aplicación:

   • GenericSubject<T> (src/app/subjects/generic.ts): Implementa la interfaz Subject con una lista de observers y métodos para gestionarlos.
   • ReverseLogisticsItemSubject (src/app/subjects/item.ts): Extiende GenericSubject para elementos de logística inversa.
   • Varios emitters en src/app/observers/sns/: Implementan la interfaz Observer para emitir eventos a AWS SNS cuando son notificados.

3. Casos de uso:

   • CreateReverseLogisticItem: Extiende ReverseLogisticsItemSubject y notifica a los observers cuando se crea un elemento.
   • Otros casos de uso que extienden ReverseLogisticsItemSubject y notifican a los observers cuando se actualizan los elementos.

Flujo de operación

1. Los observers (emitters) se suscriben al subject (ReverseLogisticsItemSubject).
2. Cuando un caso de uso realiza una operación en un elemento, llama al método notify en el subject.
3. El subject notifica a todos los observers suscritos llamando a su método update.
4. Los observers (emitters) reciben la notificación y utilizan el ReverseLogisticsEventDispatcher para emitir eventos a AWS SNS.

Patrón Repository

El patrón Repository es un patrón de diseño estructural que separa la lógica que recupera datos del almacenamiento subyacente de la lógica de negocio que actúa sobre los datos.

Implementación

En el microservicio de Logística Inversa, el patrón Repository se implementa para proporcionar una separación limpia entre la capa de dominio y la capa de acceso a datos.

Componentes clave:

1. Interfaces en la capa de dominio:

   • ReverseLogisticItemRepository (src/domain/item/repository.ts): Define la interfaz para acceder y persistir elementos de logística inversa.

2. Implementación en la capa de infraestructura:

   • MongoReverseLogisticItemRepository (src/infrastructure/repositories/reverse-logistic-item/index.ts): Implementa la interfaz del repositorio utilizando MongoDB.

3. Casos de uso:

   • Varios casos de uso que utilizan el repositorio para acceder y persistir datos.

Beneficios

• Desacopla la capa de dominio de la capa de acceso a datos
• Hace que el código sea más testeable al permitir que el repositorio sea mockeado
• Centraliza la lógica de acceso a datos
• Proporciona una API limpia para que la capa de dominio acceda a los datos

Patrón Dependency Injection

El patrón Dependency Injection es un patrón de diseño que implementa la inversión de control para resolver dependencias.

Implementación

En el microservicio de Logística Inversa, la inyección de dependencias se implementa utilizando funciones proveedoras que crean y configuran dependencias.

Componentes clave:

1. Funciones proveedoras:

   • src/infrastructure/providers/: Contiene funciones proveedoras para repositorios, servicios, casos de uso y observers.

2. Uso:

   • Las dependencias se inyectan en los constructores de las clases que las necesitan.
   • Las funciones proveedoras aseguran que las dependencias estén correctamente configuradas y compartidas cuando sea necesario.

Beneficios

• Desacopla la creación de dependencias de su uso
• Hace que el código sea más testeable al permitir que las dependencias sean mockeadas
• Centraliza la configuración de dependencias
• Asegura que las dependencias estén correctamente inicializadas antes de su uso