Cómo crear un mejor software: el papel de la narración de historias de dominio en DDD

Estos proyectos solían derivar en interminables idas y venidas con el equipo de Producto, intentando descifrar el comportamiento esperado y los casos extremos. El resultado: reuniones improductivas, frustración y tiempo perdido.

DDD y el Lenguaje Ubicuo

Con DDD, el escenario cambia radicalmente. El objetivo es alinear a todos los expertos del dominio —desarrolladores, analistas de negocios, gerentes de producto— en un lenguaje ubicuo: un vocabulario común que refleja el problema y sus soluciones. Este modelo de dominio compartido encapsula los puntos débiles de los usuarios, sus necesidades y el contexto del negocio.

Resolución de Problemas con DDD (Diagrama)

Diagrama 2: Flujo colaborativo con DDD: un lenguaje ubicuo conecta a todos los involucrados.

El lenguaje ubicuo surge de reuniones donde se discuten términos y perspectivas. Pero, ¿cómo traducimos ese conocimiento en algo tangible? Ahí entra la Narración de Historias de Dominio.

Atrás quedaron los días en que, como desarrollador de software en una empresa de productos, recibías una lista de requisitos vaga y te lanzabas a un proyecto sin entender el problema real. Solo tenías frases sueltas sobre funcionalidades y restricciones, pero ninguna visión clara del dolor del usuario o del propósito del sistema.

Resolución de Problemas sin DDD (Diagrama)

Diagrama 1 y 2: Flujo caótico sin DDD: desarrolladores, producto y stakeholders en un ciclo de reuniones y malentendidos.

¿Qué es Domain Storytelling?

La Narración de Historias de Dominio es una técnica colaborativa que convierte el conocimiento del dominio en software. A través de historias visuales, captura flujos de trabajo, entidades y relaciones, sirviendo como puente entre las ideas de los stakeholders y el código.

Elementos Básicos del Lenguaje Pictográfico (Diagrama)


Diagrama 3: Los 4 elementos del lenguaje pictográfico: Actor, Objeto de Trabajo, Acción y Número de Secuencia.

El lenguaje pictográfico usa cuatro elementos simples:

- Actor: Quien realiza la acción (ej. "Cliente").

- Objeto de Trabajo: Lo que se manipula (ej. "Contrato").

- Acción: El verbo que conecta actor y objeto (ej. "Firma").

- Número de Secuencia: Orden de los pasos.

Ejemplo: "Un cliente firma un contrato" se dibuja así:


Diagrama 4: Representación visual de "Cliente firma Contrato".

Reglas Clave

- Actores únicos: Un actor no se repite, aunque realice varias acciones.

- Objetos duplicados: Cada acción sobre un objeto requiere su propia instancia.

- Sin condicionales: Se basa en escenarios específicos, no en lógica if/else.

Alcances del Lenguaje Pictográfico

1. Granularidad: Nivel de detalle (¿general o específico?).

2. Punto en el Tiempo: Presente, pasado o futuro deseado.

3. Pureza del Dominio: ¿Físico (ej. taquilla) o digital (ej. sitio web)?

---

Cómo Implementar Domain Storytelling

Paso 1: Reunir a los Stakeholders

Convoca a todos —desarrolladores, analistas, gerentes— en una sala (o videollamada). El objetivo es compartir conocimientos y perspectivas sobre el problema.

Paso 2: Definir Alcances

Antes de dibujar, acuerda la granularidad, el punto en el tiempo y la pureza del dominio. Por ejemplo: "Vamos a detallar cómo un cliente compra un coche hoy, en un proceso físico".

Paso 3: Contar y Dibujar Historias

Usa el lenguaje pictográfico para narrar flujos. Ejemplo práctico: "Un cliente compra un coche con financiamiento".

Diagrama de Ejemplo: Compra de un Coche


Diagrama 5: Flujo de "Cliente compra coche con financiamiento" usando lenguaje pictográfico.

- Cliente → Solicita coche → Concesionario.

- Concesionario → Evalúa riesgo → Contrato.

- Cliente → Firma contrato → Concesionario.

Paso 4: Identificar Contextos Acotados (Bounded Contexts)

Analiza el diagrama para separar dominios. En este caso:

- Evaluación de Riesgos: Donde se vota el contrato.

- Ventas: Donde se firma el contrato.

Entidad "Contrato" en Contextos (Diagrama)


Diagrama 6: "Contrato" como entidad compartida entre Evaluación de Riesgos y Ventas.

Paso 5: Iterar y Escalar

Repite el proceso para otros flujos, refinando el modelo de dominio y traduciéndolo a código.

---

Estructura del Diagrama en Papel

Divide la hoja en tres secciones:

- Izquierda: Diagrama pictográfico con actores, objetos y acciones.

- Derecha: Notas, suposiciones y alcances.

- Abajo: Contextos acotados identificados.

Ejemplo Práctico: "Cliente compra palomitas en el cine"


Diagrama 7: Flujo completo con notas y contextos en una hoja estructurada.

- Flujo: Cliente → Pide palomitas → Cajero → Entrega palomitas → Cliente.

- Notas: "Escenario feliz, pago en efectivo".

- Contexto: "Venta de snacks".

---

Por Qué Domain Storytelling Mejora el Software

1. Alineación Total: Todos hablan el mismo idioma, eliminando malentendidos.

2. Simplicidad Visual: Los diagramas son accesibles para no técnicos, a diferencia de UML.

3. Transición al Código: Los contextos acotados y entidades identificadas guían la arquitectura.

Comparación con Event Storming (Tabla)

| Aspecto | Domain Storytelling | Event Storming |

|-------------------------|----------------------------------|-------------------------------|

| Enfoque | Narrativas visuales | Eventos y línea temporal |

| Herramienta Principal | Lenguaje pictográfico | Post-its y eventos |

| Ideal para | Flujos de usuario | Procesos complejos |

---

Notas y Recursos

- Alternativa: Domain Storytelling complementa Event Storming. Más en [Lucidchart DDD](https://www.lucidchart.com/blog/ddd-event-storming).

- Lectura Recomendada: Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software de Stefan Hofer y Henning Schwentner.

- Inspiración: Diagramas adaptados de [domainstorytelling.org](https://domainstorytelling.org/).

---

Conclusión: Un Software Mejor con Historias

La Narración de Historias de Dominio transforma el caos de requisitos vagos en un proceso colaborativo y claro. Al contar historias con un lenguaje pictográfico, alineas equipos, descubres contextos y construyes software que realmente resuelve problemas. En 2025, con herramientas como ChatGPT para refinar estos flujos, esta técnica es más poderosa que nunca. ¡Pruébala en tu próximo proyecto y dibuja el camino hacia un mejor software!

---

3. Diagrama 5: Usa flechas numeradas para el flujo del coche, con colores para diferenciar contextos.

4. Diagrama 6: Muestra "Contrato" como un nodo central con ramas a cada contexto.

5. Diagrama 7: Estructura en tres partes (flujo, notas, contextos) con un diseño limpio.