La orquestación inmediata y los hechos consultables no necesitan la misma representación.
Dos estados, dos responsabilidades
Ciclo operativo
Evento de inicio
→
Estado del journey
→
Siguiente acción
Registro de cliente
Eventos de negocio
→
Perfil consultable
→
Sistemas consumidores
Diagrama genérico. No reproduce una arquitectura de cliente.
Un journey puede necesitar estado de inmediato, mientras segmentación, gobierno y Decisioning necesitan hechos acotados y fáciles de consultar. Forzar una única representación para ambos crea objetos frágiles.
El estado operativo se optimiza para actuar. El perfil consultable expone solo los hechos duraderos, y los eventos siguen siendo el histórico auditable.
Señales en producción
Objetos de perfil que crecen con cada journey.
Atributos imposibles de reconstruir tras un fallo.
Segmentos que dependen de campos operativos.
Arquitectura recomendada
Clasificar cada estado por latencia, durabilidad, consumidor y capacidad de reconstrucción antes de elegir almacén.
Mantener el evento como evidencia y subir al perfil solo lo que la operación necesita consultar.
Cuándo no aplicarlo
No duplicar un hecho estable ya disponible con la latencia necesaria.
No crear un atributo de perfil sin consumidor concreto.