El real valor del Diseño Guiado por Dominios

En la actual tendencia de Transformación Digital, las empresas de avanzada han adoptado los aceleradores que trae la Cloud, tales como las arquitecturas de Microservicios, pero sin embargo si no llega al nivel esperado a las necesidades del negocio, no va a ser para nada útil. Entonces es cuando Diseño guiado por el dominio (DDD) aparece. Como bien indica su nombre, se centra en el dominio de un negocio específico.
De hecho, para diseñar un buen software, es importante saber sobre qué trata ese software. Para crear un sistema de software para un banco, se necesita de un buen entendimiento de los procesos que se llevan a cabo en el, uno ha de entender el domain del banco.

¿Que es Diseño guiado por el dominio ?

En el desarrollo de software, el enfoque del diseño guiado por el dominio se utiliza para necesidades muy complejas, para conectar la implementación a un modelo en evolución de la idea principal del modelo de negocio. Pone el foco en el problema relevante y básicamente ayuda a identificar la arquitectura e informar sobre los mecanismos que el software necesita replicar.
Diseño guiado por el dominio tiene un valor estratégico y se basa en mapear la idea de negocio domain en los artefactos del software. Organizando los artefactos del código en línea con el problema de negocio, usando el mismo lenguaje.
Diseño guiado por el dominio no es una metodología, trata de el diseño de la arquitectura del software, dando una estructura con unas prácticas de toma de decisiones que ayudan a proyectos de software con dominios complicados.
El enfoque DDD fué introducido por Eric Evans en el libro “Domain-Driven Design: Tackling Complexity in the Heart of Software“.

¿Qué es el dominio? Área temática o campo a la que un usuario aplica un software.
¿Qué es el modelo de dominio? Representa la terminología y los conceptos clave del dominio del problema. Identifica las relaciones entre las entidades incluidas dentro del ámbito del dominio del problema, identifica sus atributos y proporciona una visión estructural del dominio.
Domain driven design es un enfoque para el desarrollo de software definido por Eric Evans en su libro Domain-driven design: Tackling Complexity in the Heart of Software, que se centra en un modelo rico, expresivo y en constante evolución para resolver problemas del dominio de una forma semántica.

Lenguaje común (Ubiquitous language)

Uno de los mayores problemas que surgen durante el desarrollo de proyectos software es la comunicación entre los desarrolladores y los expertos del dominio.
Los expertos del dominio tienen un amplio conocimiento sobre el dominio, por el contrario, su conocimiento de la terminología técnica utilizada en el desarrollo de software es bastante limitada. Por otro lado, los desarrolladores entendemos y manejamos la terminología técnica, sin embargo, habitualmente nuestro conocimiento sobre el dominio del problema es bastante limitado. ya sea porque nunca nos hayamos enfrentado a un problema dentro de ese dominio o en caso de que si lo hayamos hecho, muy probablemente fuera desde una perspectiva o entorno distinto, ya que empresas de un mismo sector pueden enfocan sus problemas de manera totalmente distinta. Esta diferencia de lenguajes y conocimientos normalmente da lugar a situaciones en las que los expertos del dominio describen de manera confusa y ambigua qué esperan del sistema. A su misma vez los desarrolladores tenemos muchos problemas para entender el dominio del problema, y por lo tanto para entender lo que los expertos del dominio requieren del sistema.

En proyectos donde no existe un lenguaje común nos vemos obligados a realizar un proceso de traducción para poder comunicarnos con los expertos del dominio. A su vez, los expertos del dominio tienen que realizar un proceso de traducción en sentido opuesto para comunicarse con los desarrolladores. A menudo los mismos desarrolladores nos vemos obligados a realizar traducciones cuando nos comunicamos con otros desarrolladores.

Cada vez que se realiza una traducción se malinterpretan y confunden conceptos, provocando que diferentes miembros del equipo entiendan conceptos de manera diferente, y lo que es aún peor, sin ser conscientes de ello. Estas malas interpretaciones hacen que el software contenga incoherencias, y contradicciones dentro del código que provocarán errores en el sistema.

Todos estos problemas durante el proceso de comunicación entre los miembros del equipo hacen que, por un lado perdamos oportunidades de obtener un conocimiento más profundo del dominio y por otro lado, siendo aún más importante, la terminología utilizada para la comunicación no se ve reflejada en el software.

Para ser capaces de generar un lenguaje común, los desarrolladores tenemos que obtener el conocimiento necesario del dominio, mientras que los expertos del dominio deben formar parte activa en el desarrollo del software. De manera que tanto el dominio del problema, como los elementos del diseño del software (clases, relaciones, etc…) formen parte del lenguaje común y sean entendidas por los desarrolladores y los expertos del dominio. Ya que los expertos conocen en detalle el dominio, deben oponerse a cambios en el modelo que no sean adecuados para una correcta transmisión del conocimiento incluido en el dominio, siendo los desarrolladores los que deberíamos controlar posibles ambigüedades e inconsistencias que pongan trabas al diseño del sistema.

El proceso para llegar a un lenguaje común es iterativo, de tal manera que deberemos ejercitar el lenguaje y pulirlo mediante su utilización tanto en diagramas, como en escrito, y especialmente en la comunicación verbal. Esto hará que el lenguaje vaya evolucionando y cambiando. Dichos cambios deben verse reflejados en el código, por lo que deberemos ir refactorizando dicho código para que refleje los cambios que se producen en el lenguaje.

Para llevar a cabo la tarea de vincular el conocimiento del dominio a la implementación del modelo disponemos de diferentes elementos. Describiremos los elementos que son utilizados para modelar operaciones que pertenecen a un objeto concreto (entidades y value objects), y los elementos que representan actividades o acciones que pertenecen conceptualmente a más de un objeto.

Seguiremos en la parte 2 de este interesante tema….

si deseas conocer más del DDD escribanos a [email protected]