Qué es el DDD
El diseño guiado
por el dominio, en inglés «domain-driven design», o DDD, es un
enfoque para el desarrollo de software.
El DDD no es una
tecnología ni una metodología, sino un conjunto de prácticas y
terminologías que aportan valor a la hora de tomar decisiones sobre
el diseño de software.
El DDD tiene más
que ver con que ver con sobre el debatediiscusiónscusión debate,,
la escucha, el entendimiento, el descubrimiento y el valor de negocio
en un esfuerzo por centralizar el conocimiento del dominio. Si se es
capaz de entender el negocio se puede participar en el proceso de
descubrimiento del modelo de software para producir un lenguaje
ubicuo.
El lenguaje ubicuo
es el lenguaje común de los expertos del dominio y los
desarrolladores. Este facilita la comunicación entre todas las
partes implicadas, por lo que todos saben que está pasando con el
negocio.
Otra característica
del DDD es que todo está basada en el dominio siendo este una
abstracción del negocio.
Una vez que los
conceptos del dominio están definidos en el lenguaje común se puede
modelar el mismo. Un modelo de dominio es una parte muy específica
del dominio de negocio. Este modelo se implementa como un modelo
objeto con unos datos y un comportamiento con un significado literal
y preciso dentro dcon
el negocio.
Nunca se trata de
modelar todo el negocio en un único y enorme modelo de dominio si no
que los modelos tienden a ser pequeños y muy enfocados.
Qué valor aporta DDD
El DDD aporta,
principalmente, los siguientes valores:
-
Involucra a los expertos de dominio y a los desarrolladores durante el diseño del software por lo que este tiene sentido para todos los implicados y no sólo para los desarrolladores.
-
El software desarrollado tiene un significado semántico para los expertos de dominio.
-
Supone una mejor comprensión del negocio para todos los implicados ya que el negocio está en constante evolución.
-
El conocimiento del software no está centralizado exclusivamente en los desarrolladores si no que al estar involucrado el negocio estos también tienen el conocimiento.
-
Mejora la comunicación entre los expertos del dominio y los desarrolladores al utilizar el lenguaje ubicuo con lo que no se necesita hacer traducciones.
-
El DDD provee técnicas de desarrollo de software que dirigen el diseño estratégico y táctico.
El diseño
estratégico tiene el objetivo de dirigir el negocio por lo que
se centra en definir los distintos aspectos del negocio y priorizar
aquellos que aporten un mayor valor.
El diseño
táctico dispone de herramientas de modelado para el desarrollo
de los entregables de software ejecutables. Estas herramientas
permiten analizar y desarrollar software con el modelo mental de los
expertos de dominio.
Cuando hay que usar el DDD
El factor
fundamental a tener en cuenta es si la inversión derivada de aplicar
el DDD aporta valor al proyecto, pues hay que hacer una inversión de
tiempo y esfuerzo.
El DDD no aporta un
valor sustancial a las partes que son triviales y que son fácilmente
reemplazables. Sin embargo, sí aporta valor en aquellas áreas más
complejas, las más valorables e importantes y de mayor valor para el
sistema.
A estas áreas más
importantes las llamamos «Core Domain» y en segunda prioridad
«Supporting Subdomains». Estas son las que aportan mayor valor al
negocio.
Uno de los objetivos
del DDD es modelar un sistema complejo de la manera más simple
posible por lo que nunca se debería usar el DDD para obtener hacer
la solución más compleja.
La complejidad
dependerá de cada negocio por lo que puede ser difícil definir qué
es complejo. Una estrategia alternativa es definir qué es trivial.
Una vez establecido qué no es trivial el equipo tendrá que valorar
si merece la pena hacer la inversión de hacer uso del DDD.
Cómo hacer DDD
Para llevar el DDD a
la práctica hay que dominar dos aspectos características:
la ubicuidad del lenguaje y los contextos delimitados.
Lenguaje ubicuo
El lenguaje ubicuo
es un lenguaje que desarrollan y comparten todos aquellos que están
implicados en el desarrollo del proyecto sin importar su rol.
Los expertos de
negocio tendrán un mayor peso a la hora de desarrollar el lenguaje
ya que son ellos quienes conocen el negocio. A pesar de tener un
mayor peso deben trabajar junto con el resto del equipo, como los
desarrolladores, para confeccionar un modelo de dominio de manera que
se definan los mejores conceptos, términos y significados. El
lenguaje evoluciona a medida que los avances se van alcanzando.
Algunas
recomendaciones para definir el lenguaje ubicuo:
-
Tener una representación gráfica del dominio de manera que se puedan apreciar los distintos elementos que lo componen.
-
Crear un glosario de términos con los elementos del dominio.
-
Cualquier otro tipo de documentación aclare los conceptos, términos y significados del dominio.
-
Cualquiera de las anteriores tiene que tener la aprobación del resto del equipo. Estas podrán ir evolucionando con el tiempo por lo que habrá que ir actualizándolas.
Contexto delimitado
Los contextos
delimitados son límites conceptuales del sistema. Estos límites
resaltan un contexto y, al igual que en el lenguaje natural, los
distintos términos y frases tienen un significado específico dentro
de ese contexto. Cualquier uso de un término fuera de ese contexto
podría tener un significado diferente.
Los contextos
delimitados son tan pequeños como se puedan imaginar. Cada uno de
ellos tendrá su propio lenguaje ubicuo aunque algunos de los
términos entre los distintos contextos delimitados que componen el
sistema se puedan sobreponer.
Los retos de aplicar el DDD
Los principales
retos son:
-
Involucrar a los expertos del dominio durante todo el proceso del desarrollo del negocio.
-
La inversión de tiempo y esfuerzo necesarios para crear la ubicuidad del lenguaje.
-
Cambiar la manera en la que los desarrolladores piensan en las soluciones del dominio.
Uno de los mayores
retos es concienciar a los expertos de negocio de su implicación
durante el desarrollo.
Otro gran reto es
pensar sobre el dominio y, junto con la ayuda de los expertos de
negocio, definir el lenguaje ubicuo así como los contextos
delimitados de manera que el conocimiento del dominio sea lo más
completo posible.
El último gran reto
es cambiar la manera en la que piensan los desarrolladores ya que
estos piensan desde la perspectiva técnica. No es que pensar
técnicamente sea algo malo pero en el momento en que hay que
comunicarse con gente de otros ámbitos es mejor adaptarse y pensar
un poco menos técnicamente.
Conclusiones
Durante este
capítulo se ha visto el enfoque del DDD para el desarrollo de
software y cómo afecta sobre el diseño del software.
Se ha visto también
el esfuerzo que se requiere a la hora de involucrar a los expertos de
negocio así como a la hora de crear lenguaje ubicuo y los contextos
delimitados.
El DDD se utiliza en
partes en las que la complejidad es elevada con el objetivo de
modelarlo de la forma más sencilla posible.
También se han
visto los principales retos a los que un equipo se enfrentará.
No hay comentarios:
Publicar un comentario