De Bueno a Excelente en DDD: Event-Storming la estrategia de modelado para crear Domain-Driven Design - 9/10

‍

Fuente: Modeling your Domain with Event Storming workshop - Alex Alves

¿Por qué importa el modelado con Event-Storming en DDD?

Volvamos a InstaKran, la app de social que exploramos anteriormente. El equipo estaba enfrentando dolores de crecimiento: expectativas desalineadas, flujos de trabajo enredados y una experiencia de usuario llena de inconsistencias. Al intentar apoyar a los influencers en el lanzamiento de sus productos, el equipo de ingeniería de InstaKran tuvo dificultades para mapear las necesidades del negocio con la arquitectura del software. Fue entonces cuando recurrieron a Event-Storming. Esta técnica de modelado reunió a expertos del dominio, desarrolladores, diseñadores y product managers en una única sesión colaborativa. Usaron un lienzo digital para visualizar el flujo completo de un creador lanzando un “product drop”. Al mapear eventos como “ProductDropCreated” y “DropSoldOut”, el equipo descubrió redundancias ocultas, validaciones faltantes y suposiciones obsoletas. Event-Storming les ayudó a sacar a la luz malentendidos, definir una terminología de negocio coherente y esbozar los Bounded Contexts naturales del dominio.

Para dirigir una sesión como la de InstaKran, necesitarás algunas cosas: un equipo amplio y diverso (desarrolladores, stakeholders, operaciones), un espacio de colaboración grande (físico o herramientas como Miro/MURAL) y un sistema de notas adhesivas codificadas por color. Comienza mapeando los Domain Events (naranja), como “CreatorApproved” o “DropPublished”. Luego, trabaja hacia atrás identificando los Commands (azul), como “ApproveDrop”. Después, explora qué Aggregates (amarillo) gobiernan la consistencia y aplica las Policies (morado) clave para reacciones. Añade Actors (rosado) que ejecutan comandos y marca los External Systems (gris/verde) como pasarelas de pago. Finalmente, revisa el flujo y observa si emergen Bounded Contexts o solapamientos innecesarios.

¿Vale la pena? Sí. Porque Event-Storming fomenta un entendimiento compartido, revela reglas de negocio rápidamente y alinea a equipos multifuncionales sobre cómo debe comportarse el sistema. No es solo un ejercicio de diagramación: es un acelerador de modelado que brinda claridad e información estratégica.

¿Qué es Event-Storming en DDD?

Event-Storming es una técnica de modelado colaborativa creada por Alberto Brandolini para abordar dominios de negocio complejos. Utiliza los Domain Events como punto de entrada para descubrir flujos de trabajo, disparadores, reglas y límites. Durante una sesión, encontrarás varios elementos clave:

• Domain Events (naranja): representan sucesos significativos del negocio (por ejemplo, “OrderPlaced”).
  
  
• Commands (azul): capturan la intención detrás de las acciones (por ejemplo, “PlaceOrder”).
  
  
• Aggregates (amarillo): encapsulan la lógica del dominio y aseguran que se cumplan las reglas.
  
  
• Policies o Processes (morado): reflejan reacciones del negocio ante eventos que pueden disparar nuevos comandos.
  
  
• Actors (rosado): representan usuarios o sistemas que inician acciones.
  
  
• Boundaries & External Systems (gris/verde): ayudan a identificar integraciones y puntos de separación.
  
  

Estos componentes codificados por color aportan claridad a procesos caóticos y transforman la exploración del dominio en un lenguaje compartido.

Responsabilidades clave de Event-Storming en DDD

Event-Storming cumple un papel clave en iniciativas exitosas de Domain-Driven Design. Primero, habilita la exploración del dominio, permitiendo a los equipos descubrir lógica y decisiones que solo existen en la cabeza de las personas. También apoya el diseño estratégico al exponer los Bounded Contexts —secciones del dominio donde aplican reglas, lenguaje y lógica específicas. Al combinar participantes técnicos y no técnicos, puentea la brecha entre negocio y software, haciendo que el modelado sea accesible e inclusivo. Finalmente, Event-Storming acelera la implementación, transformando flujos de trabajo en entregables claros como aggregates, eventos, servicios y APIs.

Buenas prácticas para implementar Event-Storming

Para sacar el mayor provecho de Event-Storming, actúa como facilitador, no como controlador. Permite que las conversaciones surjan de forma natural e intervén solo para guiar. Siempre usa escenarios reales, tomados de recorridos auténticos del negocio en lugar de flujos artificiales. Evita saltar directamente a la tecnología: primero enfócate en qué ocurrió y por qué. Mantén un esquema de colores consistente para que los participantes comprendan fácilmente las diferentes partes del modelo. Por último, itera tu modelado: empieza con el nivel Big Picture para entender el dominio, profundiza al nivel Process Level para flujos de trabajo y finalmente llega al Design Level para planear la implementación.

Desafíos y anti-patrones de Event-Storming

A pesar de sus beneficios, Event-Storming puede fallar si se usa incorrectamente. Un error común es centrarse solo en los eventos, lo que lleva a modelos superficiales sin lógica accionable. Otro es excluir a los expertos del dominio, lo que resulta en una comprensión distorsionada o incompleta. Los equipos también pueden caer en la trampa de tratar el modelo como estático, bloqueándolo tras un solo taller en lugar de refinarlo con el tiempo. Cuidado con sobrecargar el canvas intentando modelar todo de una vez—esto genera agotamiento y confusión. Y quizás lo más crítico: no conectar el modelo con la implementación vuelve el ejercicio inútil. Cada hallazgo debe traducirse en código, arquitectura o documentación.

Conclusión: convertir Event-Storming en un activo estratégico de DDD

Event-Storming es liviano, poderoso e inclusivo. Descubre realidades del negocio, refina el lenguaje y revela límites del sistema —todo mientras alinea a los equipos en torno a una visión compartida. El recorrido de InstaKran ilustra la transformación: lo que comenzó como un caos de suposiciones se convirtió en un modelo claro y modular. Con Event-Storming, encontraron estructura en el caos —y tu equipo también puede hacerlo.

Estos son los siguientes temas que discutiremos en esta serie De bueno a excelente en DDD. Espero que naveguemos juntos por esta importante arquitectura:

• Eleva la calidad del código con Domain-Driven Design - 1 / 10
• Comprender los Entities y los Value Objects en Domain-Driven Design - 2 / 10
• Comprender los Aggregates y Aggregates Roots en Domain-Driven Design - 3 / 10
• Comprender los patrones de repositorios en Domain-Driven Design - 4 / 10
• Comprender los patrones de Domain-Services en Domain-Driven Design - 5 / 10
• Comprensión de los patrones de Application-Services en Domain-Driven Design - 6 / 10
• Comprender el patrón de arquitectura sugerida en Domain-Driven Design - 7 / 10
• Comprender Bounded Contexts en Domain-Driven Design - 8 / 10
• Event-Storming la estrategia de modelado para crear Domain-Driven Design - 9 / 10
• Errores comunes y antipatrones en Domain-Driven Design - 10 / 10

‍