Introducción
Domain Driven Design (DDD) es una práctica de desarrollo de software que pone el acento en el Dominio del Negocio como faro del proyecto y en su Modelo como herramienta de comunicación entre negocio y tecnología. En el equipo de desarrollo de JPA empleamos Domain Driven Design como referencia para afrontar proyectos de desarrollo de cierta complejidad. Fruto de nuestros errores pero, sobre todo, de responder a las preguntas honestas de unos compañeros y los dardos envenenados de otros, hemos ido refinando su aplicación. En este artículo te presento algunas conclusiones y prácticas que pueden facilitarte la aproximación a sus principios.
Lo más importante es el Dominio.
Parece de perogrullo ¿Verdad? Como técnico, lo que primero llamó mi atención de DDD fue el conjunto de patrones de diseño recomendados para implementar el modelo: Value Object, Entity, Service, Factory, Repository, etc. Los patrones son herramientas con larga tradición y consolidados en la industria (GOF , Martin Fowler, Eric Freeman, etc). Esta experiencia previa me llevó a pensar que eran, precisamente estos patrones, la mayor contribución de DDD. Y me equivocaba.
Lo realmente relevante del DDD es la machacona insistencia en el Dominio como fuente de verdad para el desarrollo de software. Hay que volver a él siempre que pienses que te estás desviando del camino correcto. Por ejemplo, cuando no estés seguro del valor de la funcionalidad que estás desarrollando o cuando sospeches que estás matando moscas a cañonazos (overengineering). Hay que aprender a tener el dominio siempre visible y poner en duda el valor de todo lo que no quepa en él.
“Poner en duda todo desarrollo que no esté contemplado por el dominio es la principal lección de Domain Driven Design”
¿Cómo concretamos el Dominio?
Mediante su modelo. El modelo es un conjunto de artefactos (diagramas, documentos, prototipos, etc. ) que contiene una representación significativa del Dominio. Es un paso intermedio entre el dominio del negocio y el diseño tecnológico. El valor del modelo es doble:
- Es el glosario del Lenguaje Ubicuo (“Ubiquitous Language”) . Debe ser comprensible y significativo para negocio y tecnología. Todos los miembros del equipo (incluido negocio) emplean los términos del modelo en sus comunicaciones: Historias de Usuario, Casos de Uso, Features, Tareas, etc.
- Son los cimientos y el espejo del diseño de software. El equipo de desarrollo emplea el modelo para crear un diseño que lo implementa. Pero además, mantendrá sincronizado diseño y modelo a lo largo de toda la vida del proyecto. Todo cambio en el diseño deba ser validado contra el modelo. Si como consecuencia del desarrollo se considera que el modelo debe ser ajustado, los cambios se revisan con negocio y se llevan al lenguaje ubicuo.
El punto 2 es el que requiere un mayor esfuerzo de adaptación y concentración cuando nos introducimos en DDD. Mantener sincronizado modelo y diseño es costoso. Es precisamente este coste, el que te lleva a valorar con mucho más cuidad los cambios en el desarrollo. El temido efecto: “pues ya que estoy…”. Pesar la contribución de valor de un cambio frente a su coste se convierte en un ejercicio continuo.
Elaboración del Modelo
En DDD el modelo nacerá y evolucionará mediante dos fuerzas: negocio y desarrollo. Ambos puntos de vista deben estar implicados en su creación desde el comienzo. El equipo de desarrollo debe apreciar el modelo como un producto más de su trabajo, comprender cómo le ayuda a crear mejores soluciones y sentirse tan orgulloso de la calidad del modelo como de la del código.
Delegar la creación o el mantenimiento del modelo a un analista externo al equipo, simplemente, no funciona. El equipo debe estar implicado en el esfuerzo cognitivo de análisis y modelado del dominio, sin intermediarios. Es la única forma de mantener un proceso ágil y garantizar la implicación del equipo en su mantenimiento.
Herramientas de Modelado
Ya soy un veterano de esta industria. He pasado por procesos pesados como RUP. donde se recurre sistemáticamente a artefactos de modelado para comunicar entre etapas. Cuando trabajé como business analyst o como diseñador, empleé extensivamente UML y BPMN. Posteriormente, con todo el movimiento Agile y especialmente XP, evité estas herramientas bajo el principio de que el código debía ser autoexplicativo. Como siempre, en el equilibrio se encuentra la virtud.
Las herramientas de modelado (UML entre otras) son muy útiles en la construcción de un marco significativo para todos los actores. El código, es mucho más difícil de entender por negocio. Incluso empleando frameworks específicamente adaptados para hacerlos más expresivos, como Domain Specific Languages.
El código puede ser suficiente para el diseño. La organización en módulos y componentes, una estrategia consistente de asignación de responsabilidades, así como unas prácticas de nombrado uniformes, deben hacer evidente el diseño.
Puedes apoyarte en herramientas de análisis de código que tienen muchos IDEs para crear diagramas con las entidades y dependencias presentes en el software. Esto facilita la comprensión del diseño y su validación contra el modelo. Los diagramas de análisis tienen la ventaja de ser efímeros, los creamos y los desechamos sin excesivo coste, por lo que no tenemos que gestionarlos. La ausencia de un documento de diseño evita que reemplace a la verdad reflejada por el código.
Ten cuidado con UML. Es una herramienta muy versátil que permite introducir aspectos de implementación. El Modelo NUNCA debe contener detalles como herencia, encapsulamiento o tipos concretos. Y no lo digo porque el modelo deba ser agnóstico respecto a la tecnología de implementación (raramente buscamos eso en un proyecto), sino porque pierde su papel como paso intermedio al diseño. Recuerda, es una abstracción empleada para comunicar con negocio y para guiar el desarrollo.
Es un auténtico sufrimiento estar continuamente evitando escribir detalles de diseño en el modelo. Pero este es precisamente el objetivo de DDD. Forzar el uso por todos los interlocutores de un nivel de abstracción compatible con el lenguaje ubicuo.
Gestión del Modelo
He trabajado con compañeros que prefieren crear los modelos a mano (con rotulador). El principal argumento es que reflejan la naturaleza siempre cambiante del negocio en un artefacto que está siempre “en construcción”
A míi me resulta farragoso. Si empleamos una pizarra, se borra accidentalmente. Si empleamos papel, rápidamente se llena de tachones y estamos más tiempo pasando a limpio que creando. En ambos casos, la información es difícil de compartir.
Yo prefiero un formato digital. He empleado herramientas especializadas como Visual Paradigm, o ArgoUML. Conozco todo lo que me aportan y también todo lo que me sobra. Por eso, en muchas ocasiones, prefiero emplear una herramienta más ligera, tipo diagramas. Draw.io me funciona bien para proyectos pequeños y medianos. No obstante, siempre estoy revisando las herramientas disponibles. Si estás usando alguna que te vaya bien, por favor, ponlo en los comentarios.
Conclusión: Vigila el Modelo
Domain Driven Design es una técnica que implica dos transformaciones, del negocio al modelo y del modelo al software
El modelo juega un papel central para asegurar la correspondencia entre el software y el negocio al que debe representar. El modelo debe estar siempre presente en la mente, en los ordenadores y en las pizarras de los equipos multidisciplinares. Buscamos una mentalidad de “Policía del Modelo” que persiga cualquier desviación de la consistencia de esta correspondencia.
Este es el primero de una serie sobre lo que hemos aprendido aplicando DDD en Jerónimo Palacios y Asociados. En el próximo, bajaré a la transformación del modelo en diseño. Algunas soluciones propuestas por DDD que hemos empleado y otras que no.
Imagenes :
Para saber más:
En nuestra formación DevOps profundizamos el papel de Domain Driven Design en la creación de soluciones desacopladas, fáciles de testar y de desplegar. Si te interesa saber más, rellena este formulario para que te podamos enviar información.
