Skip to content

Design Patterns

Este documento detalla los patrones de diseño utilizados en el microservicio de Product Demand.

El Observer Pattern 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.

En el microservicio de Product Demand, el Observer Pattern se implementa para notificar sobre eventos de demanda de productos y desencadenar acciones subsecuentes como cálculos de demanda diaria y categorización.

Componentes clave:

  1. Interfaces en el domain:

    • 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 application:

    • DemandSubject (src/app/subjetcs/demand.ts): Implementa la interfaz Subject para notificaciones de demanda de productos.
    • CategorizationSubject (src/app/subjetcs/categorization.ts): Implementa la interfaz Subject para eventos de categorización.
    • CreateDemandPerDayObserver (src/app/observers/create-demand-per-day.ts): Implementa la interfaz Observer para crear registros de demanda diaria cuando cambia la demanda.
  3. Casos de uso:

    • CreateProductDemand: Extiende DemandSubject y notifica a los observers cuando se registra una nueva demanda de producto.
    • Categorize: Extiende CategorizationSubject y notifica a los observers cuando los productos son categorizados.
  1. Los observers se suscriben a los subjects durante la inicialización de la aplicación.
  2. Cuando se crea o actualiza una demanda de producto, el caso de uso notifica a todos los observers suscritos.
  3. El CreateDemandPerDayObserver recibe la notificación e invoca el caso de uso CreateDemandPerDay.
  4. Cuando ocurre la categorización, el caso de uso Categorize notifica a los observers, que pueden desencadenar eventos a sistemas externos a través de SNS.

El Either Pattern es un patrón de programación funcional utilizado para el manejo de errores y para representar cálculos que podrían fallar.

El microservicio de Product Demand utiliza el Either Pattern extensivamente para el manejo de errores y para hacer más explícito el flujo de operaciones.

Componentes clave:

  1. Tipo Either:

    • Proporcionado por el paquete @justomx/either
    • Representa un valor de uno de dos tipos posibles (una unión disjunta)
    • Generalmente usado como Either<Error, SuccessValue>
  2. Implementación en casos de uso:

    • Los casos de uso devuelven Either<BusinessError, SuccessValue> para representar éxito o fracaso
    • EitherAsync se utiliza para operaciones asíncronas
  3. Ejemplos de uso:

    • Las operaciones de repository devuelven tipos Either
    • Los casos de uso encadenan operaciones usando map, flatMap y otras operaciones monádicas
    • Manejo de errores con onLeft y manejo de éxito con onRight
  • Manejo explícito de errores sin excepciones
  • Composición de operaciones con fallos potenciales
  • Seguridad de tipos para casos de error
  • Flujo de código más limpio y predecible