A pesar de su efectividad, muchos desarrolladores pasan por alto el DDD, y creemos que el Event Storming es una gran manera de introducirlo sin tan siquiera nombrarlo.

Event Storming & Domain Driven Design

Event Storming es una exploración y modelado colaborativo de workshops complejos de dominios de negocio. Involucra la unión de todos los stakeholders de un proyecto para alinearse en una comprensión tecnológicamente-neutral del dominio de negocio y del problema acuciante. Esto sitúa la solución en el contexto de negocio apropiado, ayudando a asegurar que los expertos en negocios y los expertos en tecnología llegan a un entendimiento antes de construir un sistema.

Es un proceso altamente colaborativo, y puede ayudar a que una cantidad importante de conocimientos salgan a la superfície, que de otro modo se quedarían enterrados entre individuos y equipos. Además, es una forma excelente de capturar la totalidad del entorno del producto, sus necesidades y objetivos, y valorar su complejidad. Event Storming se apoya en el aprendizaje en grupo, y es una forma divertida de integrar los equipos de producto y desarrollo.

Ayuda cuando los equipos quieren crear soluciones alternativas conjuntamente visualizándolas y seleccionándolas. Event Storming también puede ser útil para equipos con productos maduros para ordenar el proceso y encontrar cuellos de botella y áreas de conflicto. Es también una oportunidad única para aprender sobre dependencias en la totalidad del dominio que pueden ser menos visibles durante el día a día, pero que pueden afectar significantemente decisiones mechas sobre el producto, tanto a nivel técnico como de negocio.

Es extremadamente importante proporcionar un espacio ilimitado de modelado, muchos post-its de varios colores, marcadores, cinta de enmascarar y, finalmente, una atmósfera relajada. Usando una pared grande y post-its, un equipo puede esbozar un diseño de sistema de software en unas pocas horas. De hecho, Event Storming permite introducir patrones de forma menos abstracta y sumergirte en de pleno en el mundo del Domain Driven Design. Event Storming y DDD nos permiten modelar un sistema de forma asíncrona, ideal para el análisis y el diseño de sistemas reactivos cloud-native.

Empezar es fácil: los stakeholders simplemente empiezan a idear y redactar eventos de negocios interesantes en post-its y se enganchan en una superficie. Luego toca crear los flujos: un flujo de eventos son simplemente eventos en orden de izquierda a derecha, el orden representando el tiempo. Los eventos pueden tener su raíz en comandos, pero también pueden estar provocados por personas, tiempo, documentos o eventos externos o en cascada. Normalmente, a continuación los eventos y comandos se agrupan en agregados. Cada agregado representa un concepto específico de negocio que tenga responsabilidad local. Y luego, es la hora de discutir el lenguaje ubicuo. Todos los individuos involucrados en el desarrollo del producto deberían hablar el lenguaje del dominio para apoyar una comprensión mutua. El Bounded context es el marco en el que aparece un término, determinando su significado. Cada contexto tiene una frontera clara y es consistente, teniendo sus propias normas pero siguiendo comunicándose con otros.

Un workshop de Event Storming es una experiencia muy dinámica. Puede empezar con un flujo de eventos sencillo, pero tras unos cuantos eventos emergen en un workspace, una discusión más detallada está destinada a suceder. De forma contraria técnicas de modelado más formales, como la UML, la comunicación y la discusión son los resultados más críticos que salen de este ejercicio.

Esto no significa que los equipos no puedan mantener los resultados del workshop en forma de diagramas u otros artefactos, pero la base del Event Storming es principalmente sobre el libre flujo de comunicaciones.

La meta del Event Storming y el Domain-Driven Design (DDD) es establecer un lenguaje tecnológicamente independiente y una detallada comprensión de las necesidades y procesos de negocio. Esto permitirá los expertos del dominio del negocio – aquellos más familiarizados con el dominio del stock trading y el rol que los negocios juega en el mismo – a comunicar su conocimiento del dominio con el resto del equipo. Los stakeholders involucrados en un workshop de modelado pueden incluir expertos en tecnología, gestión de proyectos, especialistas en experiencia de usuario, analistas de QA y cualquier otra persona involucrada en la ejecución de un proyecto; no obstante, la gente más importante a añadir son los expertos en el dominio de negocio.

Eric Evans, líder de opinión en diseño de desarrollo, Domain-Driven Design y modelado de dominio, dice: “El corazón del software es la habilidad de solucionar problemas de DDD para el usuario.” Esto significa que, cuando desarrollan software, los desarrolladores no deberían poner el foco principal en la tecnología, sino en el lado del negocio, es decir, el área funcional a la que queremos dar apoyo: el dominio.

El DDD distingue entre tres tipos de dominios:

1. Dominio Core
Qué convierte la plataforma en algo especial, la pequeña porción de experiencia y software que da la ventaja en el mercado.

2. Subdominios Genéricos
Los necesarios para que la plataforma sobreviva, pero sin ser intrínsecamente un factor competitivo.

3. Subdominios de Apoyo
Algo que no tiene suficiente propósito general para estar disponible off-the shelf, y necesita ser desarrollado de forma personalizada.

Entender si estás o no en el core es vital, ya que te ayuda a tomar decisiones importantes relativas a los esfuerzos de inversión y desarrollo.

En el dominio core resulta extremadamente beneficioso trabajar con algunos desarrolladores internos que tengan una comprensión a largo plazo del problema así como fácil acceso a los expertos clave del dominio para fomentar una colaboración exitosa: más calidad genera más ingresos.

Además, a partir de un cierto nivel, más calidad no se convierte en más ingresos en dominios de apoyo, que usualmente son cost-driven. Si estás en el subdominio genérico, es recomendable usar una solución de software existente pues no será un gran diferenciador.

Aprender sobre estas distintas áreas y sus distinciones puede incrementar la conciencia sobre en qué centrarse y qué preguntas hacerse en un futuro. También ayuda saber si el respectivo proyecto de desarrollo de software va a cambiar las normas o si solo va a jugar un rol secundario. Aunque todo es importante para el negocio, no todo lo es en la misma medida. DDD permite a los equipos a aprender constantemente sobre el negocio y traducir estos hallazgos en software que funciona, el cual entrega software que funciona.

Los siguientes formatos de workshop Event Storming se usan con frecuencia en el campo de DDD:

• Big Picture EventStorming
  Permite la exploración colaborativa de un flujo de negocio entero, buscando las perspectivas e intereses divergentes de los muchos stakeholders involucrados.
• Process Modelling EventStorming
  Se centra en el diseño colaborativo de procesos eficaces, aprovechando una notación no especializada, con el fin de permitir la colaboración interdisciplinaria de los stakeholders técnicos, de negocio y UX-CX.
• Software Design EventStorming
  Añade un nivel de profundidad al formato anterior al explorar las partes móviles de una implementación de software de la solución e inyectando progresivamente una gramática más rigurosa.

Un Big Picture EventStorming normalmente involucra alrededor de 10-15 personas, a veces hasta 30, que exploran en colaboración todo lo que sucede dentro de una línea de negocio creando una línea de tiempo de eventos a partir de notas adhesivas en un área de modelado “infinita”. Un Big Picture EventStorming ayuda a identificar Bounded Contexts junto con el equipo de desarrollo: unidades de lenguaje homogéneo y consistencia de modelos, que juntos forman un todo heterogéneo. Dentro de este contexto, definimos un lenguaje ubicuo, donde cada término tiene exactamente un significado, y sólo uno. Al diseñar un sistema fuera de contextos limitados, el problema puede resolverse a la vez, sin complicarnos la vida más de lo necesario al tener que implementar costosas soluciones de compromiso. Es una buena estrategia para detectar el core domain e identificar candidatos de “cuello de botella”, cuya mejora podría beneficiar significativamente a todo el sistema.

El resultado de un taller de Big Picture EventStorming es un gran mapa de la comprensión del grupo del negocio en el momento del modelado, nunca un resultado final. Sólo puede interpretarse como una instantánea de los conocimientos de los participantes y, por lo tanto, sirve como punto de partida para una mayor exploración, más que como un objetivo en sí mismo.

Basándose en el panorama general, los participantes pasan a las partes de Modelado de Procesos y Diseño de Software.

El equipo trabajará a través del proceso de modelado para establecer primero una comprensión technology agnostic del dominio de los negocios de comercio de acciones, utilizando expertos en negocios como fuente de ese conocimiento. Luego, el equipo traduce esos conceptos de dominio directamente a la lógica de dominio en su código, utilizando el lenguaje de dominio apropiado. Esto permitirá a los expertos en tecnología y a los expertos en negocios mantenerse alineados a lo largo de todo el diseño.

Se trata de modelar el flujo de eventos y comandos, asignar comandos y eventos a varios subdominios que pueden ser implementados por diferentes equipos y establecer las interfaces entre subdominios.

El DDD nos da los planos para transformar el resultado de una sesión de Event Storming en modelos que son lo suficientemente formales como para usarlos en la arquitectura y la construcción de un sistema del mundo real.

En conclusión, me gustaría destacar las ventajas clave de Event Storming:

Rápido
El enfoque de Event Storming reduce el tiempo necesario para crear un modelo de dominio de negocio integral. Lo que solía llevar semanas se puede lograr en horas durante un solo workshop.

Sin Complicaciones
En lugar de utilizar UML complejos, el Event Storming descompone el proceso en términos sencillos que puedan comprender tanto los stakeholders técnicas como los que no lo son.

Engaging
Uno de los objetivos del Event Storming es hacer que el modelaje sea divertido. Es un enfoque práctico para el modelado de dominios que invita a cada persona a participar e interactuar. Además de ser más placentero, el Event Storming también resulta en ideas más valiosas a medida que los participantes se involucran más en el proceso y ofrecen sus sugerencias y experiencia.

Efectivo
El Event Storming no es un modelo de datos. En cambio, resulta en un modelo de comportamiento completo que puede ser rápidamente implementado y validado.

Tal vez el mayor valor del Event Storming está en las conversaciones que genera. Los equipos pueden utilizar el conocimiento adquirido durante el workshop para informar futuros procesos de modelado y construir software a partir de ellos, o simplemente pueden utilizar el Event Storming para comprender mejor los procesos de negocio y tomar mejores decisiones en el futuro.

Si estás interesado en saber más sobre Event Storming, te recomiendo que leas estos dos libros:

1. Introducing EventStorming book por Alberto Brandolini
2. Domain-Driven Design: Tackling Complexity in the Heart of Software por Eric Evans

Si estás interesad@ en saber más sobre Event Storming, te recomiendo asistir a nuestro curso de Event Storming que damos en Apium Academy. Haz click aquí para saber más!