Skip to main content
Depende de core; nunca de loyalty, crm ni identity.
El inglés es la versión autoritativa: ../../../modules/messaging/.

Hoja de ruta

Nueve entregas. Seis componen F1a, porque todo otro módulo necesita notificar a alguien.

El corte, explicado

  • La cascada va primera (0001). resolveChannels() es lo que todo otro módulo llama para preguntar “¿puedo notificar a esta persona, y por dónde?”. Nada más del módulo significa algo sin ella.
  • Envíos y despacho van separados (0003, 0005). Registrar que un mensaje existe y sacarlo bajo un rate limit compartido son problemas distintos: uno es una máquina de estados, el otro es equidad entre tenants.
  • Los adaptadores son una sola entrega (0006), no uno por canal. Implementan el mismo puerto con el mismo contrato; separarlos repetiría el mismo spec cuatro veces.
  • Las campañas son F1b (0007). F1a necesita que las notificaciones transaccionales funcionen — puntos acreditados, cupón emitido, OTP. Los blasts de marketing pueden seguir.
  • SMS va al final y aparte (0009) porque es el único que necesita un vendor nuevo, y eso necesita su propio ADR (DEC-E1).

La única regla que justifica todo el módulo

Todo envío pasa la cascada y todo envío verifica supresiones. No hay camino —ni transaccional, ni interno, ni “solo esta vez”— que llegue a un adaptador de canal sin ambas cosas.