La persistencia define cómo tu sistema recuerda lo que pasó, y elegir entre event sourcing y durable state marca la diferencia entre guardar solo el presente o reconstruir toda la historia. Esta decisión es clave para arquitectos que diseñan sistemas con auditoría, compliance o trazabilidad, como el caso del Banco Interamericano de Desarrollo.
¿Qué es durable state y cuándo conviene usarlo?
Cuando guardas el estado del modelo de dominio, tienes una tabla que sobrescribe la información con cada operación de escritura. Es el enfoque clásico de los sistemas CRUD: create, retrieve, update and delete.
Imagina una tabla persona con el registro del señor Smith, su estado civil y una fecha de actualización. Si cambias su nombre y luego su estado civil dos veces, la tabla solo conserva el último valor. La historia previa desaparece.
¿Qué es durable state? Es un patrón de persistencia donde almacenas únicamente el estado actual de una entidad, sobrescribiendo los valores anteriores con cada cambio.
Este modelo funciona perfectamente en muchos casos, pero tiene un límite claro: si alguien pregunta cuál era el estado civil de John Smith el 1 de febrero de 2025, no puedes responder. Tu sistema olvidó.
¿Cómo funciona el patrón event sourcing en la práctica?
Con event sourcing almacenas los hechos, no el estado. Cada cambio queda como un evento inmutable que describe algo que ya pasó.
Piensa en una tabla PersonaEventos donde guardas registros como estos:
- La persona ha sido registrada con su carga inicial de datos.
- El nombre ha sido modificado en una fecha específica.
- El estado civil ha cambiado, con su propia marca temporal.
- Un último cambio vuelve a modificar el estado civil.
Para conocer el estado actual, aplicas todas las modificaciones de forma secuencial. ¿Y si quieres saber cómo estaba John el 1 de febrero de 2025? Reproduces la pila de cambios hasta esa fecha y obtienes que estaba soltero. Esa reconstrucción debería ser automática o parametrizable según la fecha consultada.
¿Cuándo usar event sourcing en vez de durable state? Úsalo cuando necesites auditoría, compliance, regulaciones específicas o responder preguntas históricas sobre el estado de una entidad en un momento puntual.
Hay un detalle importante: la velocidad del cambio del modelo de datos. Si una entidad cambia mucho, la reconstrucción puede ser lenta. Pero en escenarios regulatorios, ese costo vale la pena.
¿Event sourcing es lo mismo que arquitectura orientada a eventos?
No, y aquí viene una confusión común. El patrón event sourcing se usa mucho en arquitecturas orientadas a eventos, pero no son sinónimos.
En una arquitectura orientada a eventos puedes tener un event broker que maneja eventos emitidos por múltiples servicios y notifica a los suscriptores. Ese broker no necesariamente guarda eventos de negocio como las modificaciones sobre una entidad persona; suele manejar eventos de aplicación y notificaciones entre productores y consumidores.
Un servicio puede usar event sourcing para persistir sus datos, pero no es un requisito para que la arquitectura sea orientada a eventos.
¿Cómo modelar estados y actores con diagramas de actividades UML?
En el problema del Banco Interamericano de Desarrollo existe una tabla de documentos y estados con dependencias entre tipos de documentos. Las facturas de exportación pueden ser emitidas y luego consumidas por las facturas de comercio exterior electrónicas. La tabla también indica qué actor interviene y qué herramienta utiliza en cada modificación.
Para representar esto, una máquina de estados o un diagrama de actividades UML funcionan muy bien.
Cómo se lee un diagrama de actividades UML
En un diagrama estándar usas lanes o carriles, uno por actor:
- Exportador.
- Aduana de origen.
- Plataforma de facturación electrónica de comercio exterior.
- Importador.
- Aduana de destino.
Las actividades se nombran con verbos en infinitivo. El eje horizontal representa el tiempo, así que lees desde la esquina superior izquierda hacia abajo cuando hay interacción entre actores, y hacia la derecha cuando avanza el tiempo.
Los documentos se señalizan con color amarillo y líneas rectas, e incluyes el estereotipo para indicar el tipo de documento y su estado. Así combinas acciones, estados y responsabilidades en una sola vista.
Ventajas frente al diagrama de secuencia
Este tipo de representación puede ser larga, pero suele ser más clara que un diagrama de secuencia porque muestra acciones específicas sobre objetos del modelo de dominio, asigna responsabilidades y permite intuir la transaccionalidad necesaria. No es un diagrama de proceso, pero puedes extrapolarlo usando estándares como BPMN.
¿Qué patrones acompañan a una arquitectura orientada a eventos?
Las arquitecturas orientadas a eventos son muy populares combinadas con microservicios. Estos son los patrones que conviene tener en tu caja de herramientas:
- CQRS para separar lecturas y escrituras.
- Event sourcing para persistir eventos en lugar de estado.
- Patrón saga para revertir transacciones distribuidas cuando ocurre un error.
- Coreografía para armar flujos de trabajo dentro de un proceso.
Y una advertencia final: cuidado con el event hell, un antipatrón donde emites demasiados eventos sin control o actores inesperados se suscriben a eventos y disparan consecuencias no previstas en tu arquitectura. Si ya viviste algo parecido, cuéntalo en los comentarios.
