Por Antonio Sánchez
En un club de lectura para leer el famoso libro de «Implementing Domain-Driven Design» de Vaughn Vernon, después de mucha lectura hemos decidido arrancar un proyecto donde poder aplicar todos los conocimientos que vamos adquiriendo.
El proyecto es un sistema de registro horario, al que llamaré TimeOvation durante los artículos. Un dominio lo suficientemente complejo como para aplicar DDD.
Este y los próximos artículos dedicados a este tema serán ejemplos prácticos de casos reales donde hemos encontrado mucho valor en las prácticas que hemos seguido. En este primer artículo hablaremos sobre la parte estratégica de DDD y sobre una actividad llamada EventStorming, que nos permite descubrir procesos de dominio antes de picar una sola línea de código.
Antes de hablar de EventStorming, quiero aclarar brevemente la diferencia entre DDD táctico y estratégico.
Se considera DDD táctico toda la parte técnica, puros detalles de implementación. Se considera parte táctica todas las decisiones sobre cómo se van a implementar las cosas y sobre qué patrones o arquitecturas usar en el proyecto. Generalmente, es la parte que más nos gusta a las personas que escribimos el código ya que es donde encontramos los retos técnicos.
Por otra parte, el DDD estratégico es aquel que busca comprender y modelar el dominio del negocio. Proyectando de una forma fiel, la realidad del negocio en el código.
La parte estratégica es clave, ya que fundamenta las decisiones tácticas. Si no le damos la suficiente importancia y cariño a la parte estratégica, es posible que el código entre en conflicto con la visión del negocio que tienen las personas expertas del dominio, lo que desemboca en caos y confusión a medida que el proyecto crece y cambia.
Pequeño inciso: se considera experto del dominio a toda persona que entienda en profundidad el negocio o al menos una parte de él. Un experto de dominio es alguien que sabe perfectamente cómo se debe comportar el software, es la persona a la que acudimos cuando tenemos alguna duda a la hora de implementar algo o de cómo debemos controlar un caso límite en una funcionalidad.
Existen varias actividades para trabajar la parte estratégica de DDD, en este artículo estaremos hablando sobre EventStorming.
Antes de hablar de EventStorming me gustaría definir qué es un evento.
Un evento representa algo que ya ocurrió en el sistema. En código, es una clase; en EventStorming, un post-it.
Un evento debe tener un nombre en pasado, ya que representa algo que ya ha sucedido. Para encontrar nombres de eventos podemos seguir el patrón de «sustantivo + verbo en pasado» por ejemplo: «UsuarioCreado» o «CitaModificada».
EventStorming nos ayuda a descubrir los procesos de negocio. Entendemos como proceso de negocio a un conjunto de actividades o pasos estructurados que una organización sigue para alcanzar un objetivo específico.
Esta actividad se compone de varias fases que se deben seguir para que el descubrimiento del proceso sea efectivo e iterativo. En este artículo hablaremos de las dos primeras fases, que son las que hemos trabajado hasta ahora en nuestro proyecto:
Es importante recalcar que el EventStorming se debe hacer sobre un ámbito reducido, lo que en inglés se conoce como «scope». Es imposible hacer EventStorming sobre distintos ámbitos del negocio a la vez; debemos ir uno a uno para, más adelante, integrarlos.
Es importante que en la actividad participe algún experto del negocio y no únicamente el equipo de desarrollo. Usar la terminología que se usa en el negocio para nombrar los eventos es muy importante para mantener un lenguaje ubicuo.
Para ejemplificar esto, hablemos de TimeOvation, en el negocio de una herramienta de registro horario existen varios ámbitos claramente distinguidos: usuarios, fichajes, ausencias, documentación, horarios, etc. Estos ámbitos se relacionan entre sí pero internamente se componen por procesos de negocio que debemos descubrir antes de definir cómo se relacionan los ámbitos.
En nuestro proyecto, iniciamos con el ámbito de fichajes, escribiendo post-its con los eventos de dominio.
Al principio del ejercicio es normal que tengamos ideas vagas y usar nombres que no nos encajan muy bien con la idea que tenemos en la cabeza. Pero es totalmente normal: es parte del proceso.
En nuestro caso, en la primera iteración aparecieron estos eventos:
Como te puedes dar cuenta, hay mucho caos, pero es normal. La primera fase del EventStorming puede ser la más complicada porque hay que empezar a dar sentido a esas ideas de negocio.
Sacamos en claro una cosa: El ámbito de fichajes debe ser responsable de gestionar única y exclusivamente fichajes. ¿Qué es un fichaje? Pues no lo sabemos con exactitud, de momento cada persona del equipo tiene su propia idea de lo que es.
La siguiente iteración natural es sacar de nuestra vista todo aquello que no aplica al ámbito sobre el que estamos trabajando. En un primer momento es normal que salgan cosas que no aplican pero a base de comentar ideas con nuestras compañeras y compañeros, vamos sacando cosas:
Es importante recalcar que entre las iteraciones hay mucha discusión entre los miembros del equipo, y estas discusiones son las que ayudan a aclarar las ideas y pulir los conceptos cada vez más.
Llegados a este punto, no somos capaces de refinar más los eventos, por lo que decidimos pasar a la siguiente fase con lo que tenemos.
Las líneas de tiempo son una actividad que consiste en ordenar los eventos según el orden en el que se desencadenan en el negocio. Debemos empezar por el «Happy Path», el proceso de negocio más sencillo de nuestro ámbito que no contempla errores ni casos límite.
En nuestro caso, detectamos que el proceso más simple es la creación de un fichaje:
Después de crear esta primera línea de tiempo estuvimos mucho tiempo hablando sobre qué es un fichaje y este aspecto es súper importante para que la actividad sea efectiva. El equipo se debe plantear en todo momento si los conceptos que se están usando son claro y reflejan bien la realidad del negocio.
Después de hablar mucho sobre qué es un fichaje, llegamos a la conclusión de que un fichaje es algo que se compone por dos registros de tiempo, uno de entrada y otro de salida. Ese concepto nos gusto mucho y decidimos cambiar la forma en que estamos modelando el proceso.
Aquí se puede ver claramente cómo a base de discusiones de equipo, iteramos los eventos y llegamos a un modelado mucho más fino y claro del proceso.
Después de llegar a un consenso claro sobre qué es un fichaje y sobre cómo se crea uno, empezamos a sacar líneas de tiempos como si de churros se trataran.
Aquí se pueden ver algunas de esas líneas de tiempo donde ya empezamos a modelar casos límite y procesos de negocio más complejos.
Ha sido increíble pasar de ideas vagas a una visión clara de los procesos de negocio. Esta actividad nos llevó hacerla aproximadamente 1 hora y con esa inversión de tiempo hemos clarificado mucho el proceso.
Empezar a desarrollar sin tener una idea clara del dominio es algo que nos costará mucho tiempo, que se traduce directamente en inversión económica. EventStorming es una actividad que no solos nos ayuda a crear un proyecto que sea fiel al negocio sino que ahorra muchísimo dinero.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
