• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

tecnologia

Domain Driven Design o Dominio, Dominio y Dominio

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: 

  1. 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. 
  2. 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 :

  • Matthew Henry on Unsplash
  • Etienne Girardet on Unsplash

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.

Diagnóstico de Arquitectura de Software Basado en Experto

 La Arquitectura de Software es central en la estrategia de las organizaciones que basan su negocio en el uso intensivo de la tecnología. Sus atributos de desplegabilidad y testabilidad son fundamentales para una organización que se plantee la evolución hacia DevOps, son el foco de un diagnóstico de arquitectura de software. Por otro lado, el State of DevOps Report  2018 señala como fundamental la adaptación de la arquitectura para estandarizarla y ajustarla a las necesidades de negocio. 

 Cuales son los elementos de la arquitectura de software a mejorar y cómo priorizar los cambios es el objeto fundamental del Diagnóstico de Arquitectura de Software. En publicaciones anteriores hablé sobre el valor de arquitectura y su diagnóstico, así como la metodología basada en escenarios de uso. En esta entrada te introduciré al diagnóstico basado en experto. 

Casos de Aplicación del Diagnóstico basado en Experto

En el anterior artículo sobre diagnóstico con escenarios de uso, vimos como retornaba un gran valor a la organización en forma de activos tangibles y cambios culturales. Como inconveniente, tiene un coste elevado en términos de tiempo y dedicación de personas claves para la organización. Esto hace que la aproximación basada en escenarios no siempre sea la mejor. 

En algunos contextos, cultura de empresa o situaciones especiales, se prefiere limitar el número de personas implicadas sobre el proceso. Otro caso, es que se desee obtener una visión rápida e independiente sobre las características fundamentales de la arquitectura. En estos casos, una aproximación basada en el trabajo de un experto externo puede resultar más conveniente en su relación conste-resultados. Algunos ejemplos que me he encontrado en mi carrera profesional son: 

  •     La evaluación de los activos IT de una compañía para su posible adquisición o como socios de negocio (ej, Due Diligence).
  •     Procesos de acreditación de cumplimiento de estándares o normativas reguladoras (ej, RGPD, implementación de receta electrónica).
  •     Reorganización del área tecnológica de la compañía (Ley de Conway). 
  •     Valoración del estado para un nuevo ejecutivo a cargo del área de IT. 

En general, las metodologías basadas en escenario son ideales para conducir un diagnóstico interno. La incorporación de de un facilitador externo, ayuda a consolidar esta práctica en la organización. Por el contrario, si lo que se necesita es un resultado rápido realizado por un asesor externo, la aproximación basada en experto parece más adecuada.

Herrameintas para el diagnóstico de arquitecturas de software

Proceso de Diagnóstico 

El asesor realiza el diagnóstico recabando la información disponible por la organización sobre la arquitectura y con reuniones limitadas a un conjunto muy reducido de expertos en negocio y tecnología. El propio patrocinador del estudio y un arquitecto suele ser suficiente.

A diferencia de la aproximación colaborativa planteada por la estrategia de escenarios, los atributos de la arquitectura no emergen como consecuencia del debate, sino que son identificados por el asesor y confirmados por la organización. En este sentido, distintos trabajos ponen de manifiesto que es más productivo, cuando se dispone de un stakeholder con dedicación limitada, afrontar el proceso con una dinámica de refinamiento. 

En este proceso, el asesor presenta su visión sobre los requerimientos funcionales y atributos cualitativos de la arquitectura para que el representante de la organización confirme su apreciación o plantee correcciones. Este proceso, suele ofrecer mejores resultados que la alternativa por la que el propio stakeholder los elabora. 

No obstante, el analista no puede limitarse a recabar la opinión de los representantes de la organización. En el diagnóstico experto es fundamental que el asesor contraste esta información con el análisis de los artefactos reales del sistema: código funcional y test, registro de incidencias, plataforma de despliegue, operaciones en producción, métricas, etc. Ésta es la auténtica verdad sobre el sistema, no la idealizada por sus creadores. 

El código no miente. Ahí está la verdad sobre la arquitectura

 En este contexto es especialmente importante la figura del promotor del diagnóstico, quien debe plantear un objetivo claro para el análisis,  con preguntas/dudas específicas a las que dar respuesta. Además, debe disponer de suficiente nivel ejecutivo en la organización para garantizar la disponibilidad de los expertos y el acceso a los recursos del sistema a evaluar. 

Por su parte, el analista debe disponer de una sólida experiencia en la tecnología y el negocio de la organización para poder llevar a cabo su labor de forma, principalmente, autónoma. La confianza del promotor en su nivel de conocimientos es clave para afrontar el proceso y que las conclusiones sean asumidas y extendidas a toda la organización.

Iteraciones y Alcance:

El proceso se basa en una o varias iteraciones en las que el asesor genera y refina con los expertos asignado. Su visión del contexto del negocio, la vista de la arquitectura, las decisiones arquitectónicas claves para el negocio y la realidad de su implementación. Todo ello, lleva a una enumeración de riesgos y fortalezas que constituirán la base del informe final para el patrocinador del estudio. 

La ausencia de una documentación mínima razonable, previa al inicio de los trabajos, puede desviar el foco. Hacer que la dedicación se desvíe hacia su elaboración, limitando las conclusiones ejecutivas del trabajo. En un primer contacto, debemos evaluar esta situación y revisar el alcance del proyecto con el promotor. Debemos asegurar que podemos afrontar el objetivo principal o bien, deben realizarse labores previas de preparación. 

El diagnóstico basado en conocimiento experto tiene un alcance más limitado que el elaborado con la técnica de escenarios de uso. Debido a la falta de contexto cualificado sobre el negocio y el sistema, las conclusiones están basadas en el juicio del asesor. Por ello, el foco debe reducirse a los grandes aspectos estructurales de la arquitectura de software. 

Así, el informe final puede resultar más superficial que los generados mediante trabajo colaborativo. No obstante, en contextos en los que se desea obtener un referencia independiente, cualificada y rápida para tomar una decisión ejecutiva, esta aproximación puede resultar la más efectiva. 

Conclusiones:

En esta ocasión, te he presentado el diagnóstico de Arquitectura de Software basado en experto externo, como contraste a la metodología basadas en Escenarios de Uso, ventajas e inconvenientes. Hemos visto el papel que juega el patrocinador del diagnóstico y la calificación del experto. También, hemos tratado la importancia de contrastar la visión de los desarrolladores con la realidad reflejada en el código. 

En mi próxima entrada sobre Arquitectura de Software, quiero analizar algunas herramientas para modelar las distintas visiones de la arquitectura. Como dice mi compañera Laura Jiménez, “los desarrolladores estáis todo el día dibujando cajitas”. Bueno, pues veremos esas “cajitas”. 

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad