Event storming

0
471
event-storming

En este breve tutorial vamos a hablar un poco sobre event storming.

Índice de contenidos

1. Introducción

En el desarrollo de software existen diferentes técnicas para obtener los requisitos funcionales. Muchas veces cuesta recopilar toda esa información y plasmarla en un diagrama de estados, diagrama de flujos, diagramas UML, un simple listado que nos tocará refinar y volver a refinar dia a día con los expertos de negocio, product owner, etc. Es costoso, si, porque muchas vaces no tenemos una imágen precisa y clara de como funciona un negocio.

Event storming intenta simplificar este proceso con diferentes mecanísmos que involucra a las personas adecuadas en el proceso para obtener de una forma visual el funcionamiento de un sistema de negocio.

2. ¿Qué es event storming?

Event storming es una técnica para descubrir el comportamiento de un negocio o los requirimientos del mismo. Es decir, permite recopilar eventos que se producen, los actores involucrados, servicios de terceros implicados y comandos o acciones para ejecutar las reglas de negocio.

Lo más destacado es: event storming proporciona un entendimiento común y un lenguaje ubicuo. Es decir, todo problema lo podemos plasmar en diferentes esquemas o modelos y todos los miembros son capaces de entenderlo. En ningún momento entra en detalles técnicos, esa es la gran ventaja.

2.1. Los integrantes

Es un ejercicio donde pueden participar todo el mundo, es decir, los stackeholders, expertos en negocio, programadores, arquitectos, expertos en UI, etc. Aunque es recomendable acotar el número de participantes entre 6 y 8 personas.

3. ¿Cuándo usar event storming?

La respuesta es corta: depende del problema a resolver. Todos los sistemas tiene una complejidad diferente. Cuando la dificultad es alta, es recomendable aplicar esta técnica. Además funciona muy bien cuando desconocemos totalmente el problema para poder adquirir contexto en un par de sesiones.

4. ¿Por qué usar event storming?

Porque todo los involucrados participan, opinan y deciden con el mismo objetivo y con el mismo lenguaje. Comparte visiones diferentes, opiniones y sobre todo con la misma meta.

5. ¿Cómo aplicar event storming?

Es necesario unos post-its de siete colores diferentes. Cada color representa un componente del sistema.

  • Domain event: evento importante del sistema.
  • Command: acción desencadenante de uno o varios eventos.
  • Rol: individuo quien ejecuta un comando, puede ser una persona o un sistema externo.
  • External system: sistema externo como pasarelas de pago o cualquier otro tipo de servicio que esté fuera de nuestro dominio.
  • Business rule: representa una regla de negocio.
  • Aggregate: representa el estado de nuestro sistema. Según Martin Fowler “A cluster of domain objects that can be treated as a single unit”. En resumidas cuentas es un conjunto de objetos de dominio que pueden ser tratados como una sola unidad. Vamos a verlo con un ejemplo. Imaginemos que tenemos un objeto de dominio llamado cliente, puede estar compuesto por datos personales y dirección. Tanto los datos personales como la dirección sin el cliente no tiene sentido ¿verdad?, ahí el kit de la cuestión, el cliente es el agregado y el resto son objetos de dominio. Toda modificación o actualización de cualquiera de los campos debe ser a través del cliente. De esta manera simplifica toda la lógica y las operaciones porque están centradas en el agregado.
  • View: una vista con el que un usuario interactua (no abusar de este componente, es solo para enfatizar una acción con posibles datos de entrada).

5.1. Recomendaciones

Antes de empezar hay que definir las piezas a analizar, por ejemplo, no podemos intentar aplicar event storming en un sistema que lleva 50 años funcionando para extraer todas los requisitos funcionales. No terminaríamos. Debemos establecer metas en cada sesión. En este artículo, por ejemplo, podemos decidir la creación de clientes y la asignación de citas automáticas como nuestra meta.

A continuación dejo algunas recomendacione a tener en cuenta:

  • Marcar objetivos en cada sesión.
  • Establecer un límite de tiempo, recomendable 1-2h.
  • Establecer un límite de participantes, recomendable 6-8 personas.
  • Algunas personas pueden no participar por el motivo que sea, en tal caso hay que incentivar o motivar dichas personas, por ejemplo, haciéndoles preguntas.
  • No perder el foco de la sesión, a menudo solemos desviarnos del tema.
  • No introducir temas técnicos. Solemos por naturaleza hablar de dificultades técnicas. En su lugar, debemos transmitir nuestra preocupación con lenguaje natural.
  • No hace falta llegar a la solución «perfecta». Debemos ser algo pragmáticos
    y analizar como se desarrolla el problema con algún tipo de feedback.

5.2. Procedimiento

Para poder explicar los pasos a seguir me basaré en una sistema para solicitar citas, exclusivamente en el proceso de dar de alta un cliente y asignar una cita automáticamente cuando el usuario lo requiera.

  1. El primero paso es descubrir los eventos más importantes. Los eventos deben de empezar con un sustantivo + verbo en pasado. Para un ejemplo más completo añadimos una verificación de identidad vía email.

  2. Después descubrimos los comandos o acciones, es decir, que acción es necesaria para lanzar dicho evento.

  3. El siguiente paso es descubrir quien desemboca la acción, puede ser un usuario o un sistema externo.

  4. Ahora toca descurbir sistemas externos, por ejemplo, el envío de email se hace a través de un servicio que esta fuera de nuestro dominio.

  5. Analizar posibles reglas de negocio, en este ejemplo, el cliente marca el requirimiento de una cita automática cuando es creado.

  6. Ahora toca representar los agregados, recueden, los agregados representa el estado de un sistema. En este ejemplo vemos que por un lado tenemos cliente y por otro cita. Ambos representan un estado.

  7. Podemos añadir énfasis visual en el alta de un cliente. Pero insisto, este paso no es tan importante.

  8. Organizamos los agregados en diferentes contextos. El objetivo es definir límites entre ellos. En resumidas cuentas es agrupar las responsabilidades de los agregados. Por ejemplo, en caso de Administration puede haber una gestión de usuarios y operadores, y en caso de Calendar una gestión de reservas, reuniones y tareas. Podemos ir añadiendo más y más agregados en base a las necesidades del negocio y cada uno estará «clasificado» en un contexto.

6. Aplicación

Una vez extraídos los contextos y establecidos los límites podemos tomar decisiones más "técnicas" entre arquitectos/programadores. Si nos encontramos en un entorno de DDD con un monolito, podemos decir que cada contexto es un Bounded Context. En caso de microservicios podemos partir los microservicios en contextos o cada agregado podría ser un microservicio. Da igual la decisión que tomemos, la aplicación más importante es que podemos tomar este tipo de acciones una vez analizado el sistema y ver cuales son las fronteras entre ellas.

7. Conclusión

Hemos visto un pequeño ejemplo, pero si lo extrapolamos a un problema de verdad podemos encontrar todo tipo de dificultades, por ejemplo, bloqueos, bucles, complejidad excesiva, etc. El caso es que nos ayuda detectar este tipo de imprevistos antes de ponernos a diseñar/codificar el código e incluso definir las propias historias de usuario.

Muchos de los conceptos que se utilizan durante un taller de event storming se definen en el enfoque de DDD.

8. Referencias

Dejar respuesta

Please enter your comment!
Please enter your name here