¿Cómo realizar un taller estratégico de Domain Driven Design?
DDD usando Context Mapping
En una publicación anterior estuvimos hablando acerca del potencial de Domain Driven Design como enfoque para el desarrollo de software y su impacto desde un punto de vista tanto estratégico como táctico. Te recomendamos leerlo para tener un mejor contexto:
En este nuevo artículo explicaremos los diferentes pasos que realizamos para un taller de DDD estratégico en Bancolombia, a través del uso de la herramienta Context Mapping.
Este es un taller que facilita el entendimiento de un dominio de negocio desde las capacidades que ofrece y de todo el lenguaje que hay alrededor, para posteriormente identificar soluciones tecnológicas para cada uno de los subdominios resultantes del ejercicio.
Es muy probable que, si estás iniciando en el mundo de DDD, tengas la sensación de entender los conceptos pero no saber muy bien cómo aplicarlos o llevarlos a la práctica — a nosotros también nos pasó — . Por esta razón queremos compartir la forma en que realizamos el taller de Domain Driven Design en su versión estratégica.
El taller
Preparación
El primer paso consiste en identificar cuáles son las personas con mayor conocimiento del negocio que deben participar en el espacio, además de las personas importantes de tecnología que deben estar presentes.
El espacio puede ser de manera virtual o presencial, pero recomendamos que no supere las 15 personas. En promedio, se requieren dos espacios de 3 horas, pero puede variar según la complejidad y detalle con que se quiera abordar el ejercicio.
Solicita a cada una de las personas que van a participar en el espacio que, previamente, construyan una lista de los conceptos de negocio más importantes sobre el dominio que se quiere modelar. Pídeles que te la envíen antes del día del taller.
¡Recuerda reforzar la idea de que son conceptos de negocio y no conceptos técnicos!
Depuración de conceptos
Agrupa todos los conceptos enviados por cada uno de los participantes en una sola lista (puede ser en excel o en la herramienta que prefieras) y depúrala borrando los conceptos repetidos — esto ahorrará mucho tiempo y evitará perder la atención de las personas al momento del taller — .
Es común que algunos no envíen la lista de conceptos, pero es importante cerciorarse de que al menos los principales expertos de dominio sí lo hagan.
Contextualización
En caso de que sea la primera vez que realices el taller, te vas a encontrar conque muchas personas no tienen idea sobre Domain Driven Design; de hecho, es normal que algunos de ellos estén un poco reacios a realizarlo, debido a que no entienden el valor que genera.
Por esta razón, es importante iniciar el taller dando un contexto general sobre el objetivo y los resultados esperados, así las personas notarán las ventajas que el taller ofrece y tendrán una mayor disposición para participar.
Este espacio debe ser muy corto, con unos 15 o 20 minutos debería ser suficiente. Recuerda que la prioridad es mantener la atención de las personas para lograr obtener la mayor cantidad de conocimiento del dominio en cuestión.
Definición de subdominios
Este es el momento de utilizar la lista previamente construida. Debes iniciar leyendo cada uno de los conceptos, después pregunta a los participantes si consideran que, en ese listado, están todos los conceptos, que ellos como negocio, usan en su día a día. Puede ocurrir que la respuesta sea: no; en ese caso añade todas las ideas que surjan de los participantes.
Ten presente que la lista de conceptos puede seguirse refinando en cualquier etapa del ejercicio.
Teniendo el listado de conceptos depurado, el paso siguiente es identificar los subdominios. Un subdominio es un subconjunto o división del dominio general y para identificarlos puedes realizar los siguientes pasos:
- Como equipo, agrupen los conceptos relacionados y den un nombre a esa agrupación. Por ejemplo, si tienes los conceptos: tarjeta, cuotas, pago, franquicias, puedes agruparlos en un subdominio llamado: Tarjetas de crédito.
- Asegúrate de que todos los conceptos queden ubicados en uno de los subdominios. Puedes tener tantos subdominios como sean requeridos, por ejemplo: Tarjetas de crédito, Conciliación, Consumos, Novedades, etc.
- Complementa cada uno de los subdominios con conceptos que el equipo considere que no fueron identificados en la fase inicial.
- Pregunta a los asistentes si consideran que los subdominios que han surgido representan adecuadamente el negocio o si ven necesario crear, combinar o eliminar algún subdominio.
- Intenta que la discusión no sea monopolizada por el equipo de tecnología. Haz preguntas directas a las personas de negocio y asegúrate de que el resultado obtenido realmente represente la forma en que ellos visualizan el negocio.
En este punto deberías tener un resultado como el siguiente:
Identificación de relaciones
El paso siguiente tiene el objetivo de identificar las relaciones entre los subdominios. Para continuar el ejercicio suele ser más sencillo pasar los subdominios (sin los conceptos) a una herramienta del estilo de draw.io:
Debes tomar cada uno de los subdominios y trazar una linea hacia o desde los subdominios con los que se relaciona, dependiendo de la dirección. Ten en cuenta que existen diferentes tipos de relaciones como: customer-supplier, anticorruption layer, conformist, partnership, entre otros (revisa el detalle de todos los tipos de relaciones en la documentación oficial de Domain Driven Design).
Las pregunta claves para encontrar relaciones son las siguientes: ¿Cómo se relaciona este dominio X con este dominio Y?, ¿este dominio X hace uso del dominio Y o el dominio Y hace uso del dominio X?. Dependiendo de la respuesta se traza la línea.
Adicionalmente, debes ubicar la letra U (upstream) del lado de la relación que expone la capacidad y la letra D (downstream) del lado del que la consume. Por ejemplo, si se identifica una relación entre un subdominio tarjetas de crédito y un subdominio clientes, en donde clientes consume las capacidades de tarjeta de crédito, se pone la letra U en tarjetas de crédito y la letra D en clientes.
Clasificación de subdominios
Por último, identifica cuáles son los subdominios core, de soporte y genéricos, y márcalos de colores diferentes. Normalmente los subdominios core tienden a quedar en el centro después de identificar todas las relaciones, debido a la dependencia que tienen con otros subdominios.
En el anterior diagrama, los subdominios naranjas corresponden a dominios core; los azules a dominios de soporte; y el gris a un subdominio genérico (Para tener mayor detalle sobre qué es cada uno de estos tipos de subdominios revisa el artículo que te recomendamos al inicio de esta publicación).
Recuerda que con un ejercicio de DDD estratégico se busca entender cómo está estructurado un dominio de negocio a través de las relaciones de sus subdominios para tener una visión a alto nivel.
Es importante que en este punto les preguntes a los participantes del taller si consideran que el resultado del ejercicio refleja lo que para ellos es el dominio de negocio y realices los cambios que consideres necesarios.
Como resultado obtendrás un mapa de contextos o subdominios que puedes utilizar para diseñar estrategias de adquisición de software, desarrollo in-house o hasta para planear de manera organizada la definición de API’s para estrategias productor — consumidor.
Gracias por leer el artículo, si te gustó, compártelo. Además, escribe en los comentarios la experiencia que tuviste al seguir estos pasos, o la forma en que realizas tus talleres de DDD estratégico.
