Continuamos hoy hablando de algo serio. Los equipos que crean sistemas de información aplicados con frecuencia difieren en la descripción del mismo proceso de negocio. En la discusión participan representantes del negocio, analistas, desarrolladores, probadores e ingenieros de operaciones. Cada uno tiene parte del panorama, pero no existe una descripción completa: unos hablan de formularios y campos, otros de estados y comprobaciones, otros de carga y fallos. Como resultado, los requisitos se contradicen entre sí, los plazos se alargan y las funciones implementadas no coinciden con las expectativas. Y aquí puede ayudar Event Storming. Vamos a entender qué es juntos.
¿Qué es Event Storming
Event Storming es la modelización colaborativa del dominio a través de una cadena de eventos del dominio. Un evento del dominio es un hecho que ya ocurrió y tiene importancia para el negocio. La formulación siempre está en pasado. Ejemplos sencillos y directos: pedido creado, pago confirmado, devolución tramitada. Al trabajo con eventos se añaden dos elementos. Comando — es una solicitud de cambio de estado que envía una persona o un sistema. Política — es una regla automática que se activa cuando ocurre un evento e inicia acciones posteriores. Este conjunto es suficiente para ver las relaciones de causa y efecto y pasar a soluciones técnicas sin conjeturas.
Por qué es útil para desarrolladores y analistas
Los eventos aportan una línea de referencia. Los equipos vinculan las intenciones del negocio con las interfaces y los puntos de entrada. Las políticas muestran dónde es mejor trabajar de forma asíncrona y qué debe ocurrir sin intervención del usuario.
En una sola pizarra aparecen respuestas a preguntas básicas:
- Qué se hizo
- Quién inició la acción
- En qué condiciones debe rechazarse el comando
- Qué datos son obligatorios
- Qué debe lanzarse automáticamente después del hecho
Cuando esas respuestas están registradas, las decisiones arquitectónicas surgen de forma natural. Se ve qué manejadores son necesarios, dónde separar servicios, qué mensajes publicar y qué comprobaciones incluir en las pruebas.
Glosario breve sin ambigüedades
Comando en el marco de Event Storming no es un colectivo de personas. Es una acción que entra en el sistema. Ejemplos expresados en imperativo y comprensibles para cada participante: realizar pedido, aceptar pago, cancelar el envío.
Actor — iniciador del comando. Puede ser un usuario, un servicio externo o una programación de tareas.
Agregado — conjunto de datos y reglas de integridad que cambian juntos. Un ejemplo es un pedido con líneas, importe y estado.
Límite del contexto — parte del modelo donde términos y reglas están acordados. En los límites de contexto se realizan **integraciones** con contratos explícitos.
Estas definiciones son suficientes para el trabajo práctico y coinciden con la terminología establecida.
Mini-escenario de una tienda en línea
Inicio del proceso. El usuario envía el comando realizar pedido. El sistema verifica que el carrito no esté vacío y que el cliente esté identificado. Estas comprobaciones son precondiciones del comando. Si se cumplen, el sistema registra el evento pedido creado. Es un hecho que se puede registrar en el diario y usar después. Al ocurrir el evento actúa una política. Reserva los productos e inicia el comando solicitar pago. El pasarela de pago procesa la solicitud y envía una notificación. La tienda recibe el evento pago confirmado. En respuesta se lanza la siguiente política. El pedido entra en la cola de envío y el cliente recibe un correo. Cuando el almacén empaqueta el pedido y lo entrega al servicio de mensajería, aparece el evento paquete despachado.
En este breve fragmento se ven las intenciones, los hechos, las reacciones automáticas y las zonas de responsabilidad. También surgen conclusiones técnicas. El comando realizar pedido es un POST HTTP en un punto de entrada. Los eventos de pago llegan por webhook. Es mejor implementar las políticas de forma asíncrona mediante una cola. Los invariantes del agregado pedido son simples y comprobables. No se puede confirmar el pago para un pedido en estado cancelado. No se debe cobrar el pago si no se creó la reserva.
Cómo se desarrolla la sesión
La preparación es mínima. Se necesita una superficie amplia para la línea temporal y un conjunto de tarjetas. Primero los participantes escriben eventos con frases cortas en pasado. En este paso no se discuten tablas ni formatos. El objetivo es recopilar los hechos importantes para el negocio. Luego los eventos se ordenan en el tiempo, se agrupan formulaciones similares y se aclaran las disputas. Después el equipo añade las acciones que pudieron generar cada hecho. Aquí se indican explícitamente los iniciadores y los canales. Usuario y POST, programación y tarea en segundo plano, servicio externo y webhook. La siguiente capa son las políticas. Para los eventos significativos se registran reacciones automáticas. Estas indicarán dónde hacen falta suscriptores de cola y dónde basta una transacción dentro de un mismo servicio.
Cuando eventos, comandos y políticas están relacionados, se ve qué datos son necesarios para ejecutar las acciones, qué comprobaciones son obligatorias y qué invariantes no se deben violar. En esta etapa es útil identificar agregados y límites de contexto. Donde el vocabulario y las reglas difieren aparece un límite. Ahí también surgen contratos explícitos de integración.
Qué se obtiene como resultado
Event Storming crea cinco artefactos clave:
- Flujo de eventos y acciones sin interrupciones — el principal **artefacto**. Se convierte en un diagrama de interfaces y procesamiento de mensajes.
- Lista de políticas — relación de reacciones automáticas que hay que implementar.
- Conjunto de invariantes — reglas concretas de integridad que irán a las pruebas y verificaciones a nivel de código.
- Mapa de límites de contexto — ayuda a definir dónde termina la responsabilidad de un servicio y comienza la de otro.
- Glosario de términos — evita interpretaciones distintas en requisitos y documentación.
Transición a la técnica sin capas innecesarias
Los comandos se convierten directamente en puntos de entrada. Los nombres y parámetros se toman de las formulaciones en la pizarra. El ejemplo es claro. El comando realizar pedido corresponde al método POST en la ruta orders. Los eventos pasan a ser mensajes que publica el servicio origen y procesa el servicio receptor. El evento pago confirmado es conveniente transmitirlo a través de un bus de mensajes para que el almacén y las notificaciones no dependan del código interno de pagos. La observabilidad se apoya en los mismos nombres. En el registro se escribe el nombre del evento, el identificador del agregado, la fuente y los datos clave. Las pruebas se construyen con la plantilla comando precondiciones evento esperado. Ese test es reproducible y comprensible fuera del contexto de una implementación concreta.
# punto de entrada del comando realizar pedido POST /orders { "items": [{"sku": "A-123", "qty": 2}], "customerId": "c-001", "delivery": {"type": "courier", "city": "Moscú"} } # mensaje del evento pago confirmado { "event": "payment_confirmed", "orderId": "o-100500", "paymentId": "p-777", "amount": 3500, "currency": "RUB", "occurredAt": "2025-09-21T12:10:00Z" } Errores más comunes
Cuatro errores principales y sus soluciones:
- Mezclar términos de distintos contextos
Solución: fijar el glosario y marcar los límites. - Escribir eventos con jerga técnica
Solución: formular el resultado para el negocio. - Discutir tablas y códigos antes de acordar hechos y reglas
Solución: mantener el orden. Primero eventos, luego acciones y reacciones, después interfaces y formatos. - No indicar la causa del evento
Solución: para cada hecho registrar el comando o la política que lo provocó y enumerar los datos obligatorios.
Respuestas a las preguntas que se hacen con más frecuencia
¿Qué aporta la política?
La política fija la reacción automática ante un hecho. No es un escenario de usuario ni una operación manual. La política ayuda a mantener el comportamiento del sistema estable y predecible.
¿Es necesario dividir inmediatamente en microservicios?
No. Primero se acuerda el modelo, luego se eligen los límites técnicos.
¿Se puede trabajar sin colas?
Se puede, si los eventos y las reacciones caben en un solo servicio y no requieren aislamiento temporal. Pero el propio flujo de eventos seguirá siendo útil. Es más claro que cualquier diagrama de base de datos.
Un pequeño ejemplo de conversión a criterios de prueba
El comando realizar pedido tiene precondiciones. El carrito no está vacío, el cliente está identificado. El evento esperado es pedido creado. La política al ocurrir ese evento reserva los productos. La prueba suena simple. Si el carrito está lleno y el cliente es conocido, al invocar POST orders el sistema registra el evento pedido creado, publica la tarea de reserva y devuelve el identificador del pedido. Si el carrito está vacío, el comando se rechaza con un código de error comprensible. Esas formulaciones son igualmente legibles para negocio y desarrollo.
Conclusión
Event Storming devuelve la discusión a los hechos y hace la conversación concreta. Los eventos dan la base, los comandos explican las intenciones y los puntos de entrada, las políticas describen reacciones automáticas y los límites de contexto distribuyen la responsabilidad. Tras la sesión el equipo no tiene lemas abstractos, sino un flujo de eventos concreto, interfaces comprensibles, una lista de manejadores, invariantes comprobables y un glosario. Con ese conjunto la solución se construye más rápido y los cambios no rompen el comportamiento acordado.
