Event Storming

• Se usa para transmitir las ideas de los Domain Experts a los developers.
• Se focaliza en establecer una logica de negocio y no en establezer el flujo de datos de la aplicacion.

Event-driven modeling

• Ventajas
  • Cada persona involucrada en el proceso tiene un paquete de postit y es responsable de contribuir en cada sesión.
  • Todo el mundo añade conocimiento al Lenguaje Ubicuo que se usará en el desarrollo de la aplicación.
  • Todo el mundo se focaliza en los procesos y no en la programación.
  • Muy visual y aclarador para todos los participantes.
  • Revela los malentendidos que tiene la gente antes de empezar.
  • Consigue que todos los implicados en el proyecto entiendan el Core Domain
  • Pone de manifiesto los problemas que pueden surgir antes que ocurran.
  • Se puede dividir la session en vairias fases sin que los participantes pierdan el hilo.

Lista de requisitos

• Domain Expert(s) + Developers en la misma sala.
• Mente abierta. No se tiene que ser demasiado correcto en ésta fase del desarrollo.
• Disponer de posits de varios colores (Naranja, rojo, azul claro, amarillo pálido, violeta, rosa) extra pegajosos.
• Marcador negro por persona.
• Pared blanca en la que poder trabajar.

Pasos

1. Empezad creando una serie de Domain Events en los posits. Se suele usar el color naranja para éste tipo de elementos del modelo.

   • Tener en mente que se tiene que tener en cuenta la lógica de negocio y no el código y su estructura.
   • El nombre que se escribe en la etiqueta tiene que ser un verbo en pasado. P.Ej: ProductoCreado, Item del backlog Creado.
   • Pega los posits por orden de tiempo. Es decir, de izquierda a derecha. Si no tienes claro en que posición poner un evento, pegalo en cualquier parte hasta que a medida que avences, encuentres el lugar que le coresponda en el flujo de eventos.
   • Un Domain Event que sucede en paralelo a otro, puede ser posicionado verticalmente bajo otro evento.
   • Marca con un posit rojo aquellos problemas que encuentres en el flujo, que necesitan una investigación para resolver.
   • Algunas veces, el resultado de un evento resulta en uno o varios procesos que tiene que ser ejecutados. Éstos procesos los indicaremos con un posit de color violeta. Dibuja una flecha desde el evento hasta el proceso correspondiente. Detalla los eventos correspondientes al proceso en caso de ser necesario.
   • Si crees que ya has usado todos los eventos posibles de la aplicacion, descansa hasta el día siguiente y revisa los eventos nuevamente en busca de algun evento que hayas olvidado. Del mismo modo, elimina aquellos eventos que creas que ya no son útiles.

2. Crea los commands que provocan los eventos indicados en el paso anterior. Es posible que haya eventos que sus desencadenantes provengan de otra aplicacion. Para éstos, no hace falta generar ningun command.

   • Usa las etiquetas de color azul claro para representar cada comando.
   • El formato para los comandos deve ser en imperativo. P.Ej: CrearProducto, Crear item del backlog.
   • Pon las etiquetas de tipo command a la izquierda de su correspondiente evento.
   • Si un comando sólo puede ser realizado por un ros especifico, puedes indicarlo con con un posit amarillo en la parte inferior izquierda del comando.
   • Se puede dar el caso que un command desencadene un proceso. Indicaremos éstos procesos con un posit violeta indicando con una flecha desde el comando hacia el proceso/s que se desencadena.
   • Es posible que en éste punto te des cuenta que hay procesos que desencadenan eventos que no has detectado anteriormente. Añadelos al tablero en la posicion que le corresponda.
   • Puede suceder que un comando provoque varios eventos. Sitúa el mismo comando a la izquierda de cada evento que afecte.

3. Asocia la Entity/Aggregate en la que el comando es ejecutado y que produce el evento ya asociado. Hemos dejado éste paso como tercero ya que los participantes están inmersos en el proceso de negocio y no en los datos. Si tenemos que pensar en los datos, éste es el paso para hacerlo.

   • Usarmos los posits amarillo pálido.
   • En lugar de verbos, usaremos nombres para indicar cara entidad/agregado.
   • Se colocará cada Entity entre el comando y el evento lijeramente por encima de los dos.
   • Te daras cuenta que a medida que avances en el proceso, se repetiran en varios lugares las mismas entidades. Crea la misma Entity para cada grupo.
   • Si descubres nuevos eventos por añadir al tablero, añadelos con su comando correspondiente.
   • Del mismo modo, puede que algunas entidades sean demasiado complejas y tengan que separarse en varios procesos. Crea los procesos corespondientes con posits de color violeta.

4. Agrupa por tema los grupos de posits que has obtendo y ordenalos cronologicamente. Habrás descubierto que varios elementos se comparten entre los diferentes grupos que acavas de formar. Se tiene que lidiar con ellos de la siguiente forma:

   • Se tiene que agrupar dadas las siguientes condiciones:
     • Divisiones de departamento
     • Cuando hay varias ddefiniciones ed un mismo termino segun su contexto.
     • Cuando un concepto es importante pero no forma parte del core de la aplicacion.
   • Usa un marcador para agrupar los posits segun el contexto (indicado con una linia continua) o por subdominios (indicado por una linia discontinua).
   • Tambien puedes usar posits rosa para marcar cada grupo indicando si se trata de un grupo por contexto o por subdominio.
   • Añade a los posits rosa el nombre que tendrá el Bounded Context
   • Usa flechas para indicar la direcion de comunicacion entre los diferentes Bounded Context

5. Identifica las vistas que van a necesitar tus usuarios.

   • No es necesario mostrar cada vista que va a tener la aplicacion. Indica unicamente aquellas que van a tener un gran impacto y que requeriran de un cuidado especial a la hora de desarrollarlas.
   • Para el wireframe de éstas vistas, se puede usar un posit de color verde
   • Puedes usar los posits amarillo para indicar los roles de usuario que tendran permitido acceder a dicha vista.