Diseño guiado por el dominio

INTRODUCCIÓN

Hoy en día, la complejida del desarrollo de software es una realidad, por lo que es necesario contar con herramientas que ayuden a los procesos mas importantes de la creación de algún tipo de aplicación, es por esto que en el siguiente informe se hablara de DDD( Diseño guiado por el dominio) que es un enfoque para el desarrollo de software.

Domain-driven design (Diseño guiado por el dominio)

Es un enfoque para el desarrollo de software con necesidades complejas, mediante una profunda conexión entre la implementación y los conceptos del modelo y núcleo del negocio, al referirse al dominio se refiere al negocio, por lo tanto es importante conocer muy bien el negocio al cual se dirige el software que se desarrollara.

Domain-Driven Design no es una tecnología o una metodología. Es una manera de pensar y de un conjunto de prioridades, encaminadas a acelerar los proyectos de software que tienen que ver con los dominios complicado.

Para lograr ese objetivo, los equipos necesitan un amplio conjunto de prácticas de diseño, técnicas y principios. La refinación y la aplicación de estas técnicas será objeto de discusión para este sitio, por lo general a partir del lenguaje de los patrones establecidos en Domain-Driven Design .

Cuando la complejidad va de las manos, el software no puede ser entendido lo suficientemente bien como para ser fácilmente modificado o ampliado. Por el contrario, un buen diseño puede hacer que las oportunidades de las características complejas, la complejidad más importante de muchas aplicaciones no es técnico. Es en el dominio de sí mismo, la actividad o negocio del usuario. Cuando esta complejidad de dominio no se trata en el diseño, no importa que la tecnología de infraestructura está bien concebido. Un diseño exitoso de manera sistemática debe hacer frente a este aspecto central del programa.

El diseño del dominop propone una arquitectura, el cual nos muestra que, por lo menos, vamos a contar con una capa de dominio, una capa de infraestructura, una capa de aplicación y algún cliente o interfaz de usuario que consuma esa aplicación. Los nombres de las capas en las diferentes arquitecturas pueden variar, alguna capa puede estar o no estar, o se puede dividir en dos o más, pero lo importante es que nunca puede faltar la capa de Dominio o de Negocio. Esta capa se debe aislar del resto de las capas del sistema. Esta capa será la expresión final del negocio, la implementación limpia de un modelo guiado por el dominio. Domain-Driven Design requiere sólo la capa de negocio para existir. Los objetos de dominio deben quedar libres de la responsabilidad de mostrarse, guardarse y/o responder a tareas de la aplicación, para poder enfocarse en expresar el modelo de dominio.

Algunos de los pilares de DDD son:

·         Potenciar la colaboración con los interesados y expertos del dominio. Todo el mundo tiene que ayudar a definir el modelo (el modelo es la representación del dominio, el modelo son los elementos del dominio y sus relaciones).

·         Tiene que existir un leguaje ubícuo, es decir, tiene que haber un mismo lenguaje que esté en todas partes, tanto en los expertos del dominio, como en los técnicos, como en el modelo, como en el código

·         Cualquier programador, analista o lider de proyecto tiene que participar.

·         Cuando alguien codifica tambien participa en el modelo. El código es la implementación del modelo, pero es todo lo mismo. No tiene sentido definir un modelo y luego implementar otra cosa, en tal caso el modelo ha perdido todo su valor y hemos perdido el tiempo.

·         Como el código es el modelo, si cambiamos código habrá que avisar a los interesados y expertos del dominio.

Algunos conceptos definidos por DDD:

·         Entidad: Es un objeto que tiene un identificador único en el contexto que se este tratando. 

·         Value Object: Es un objeto que tiene atributos, pero no tiene identificador en el contexto. Pueden tener comportamiento y suelen ser inmutables. Sirven para describir cosas.

·         Servicio: Son los verbos del lenguaje ubícuo. Un servicio aparece cuando tenemos una funcionalidad que no pertenece a ningún objeto del dominio, en tal caso creamos un nuevo objeto que no es del dominio y que tendrá la responsabilidad de realizar esta funcionalidad. Esto es el patrón Fabricación Pura de GRASP. No tienen estado. Tienen que tener poco código, si hay mucho es que no se está haciendo bien la Orientación a Objetos. Normalmente se limitan a “sincronizar” operaciones entre varios objetos del dominio.

·         Agregado: Es una composición de objetos. Tiene una raíz que es una entidad. Lo normal es no poder acceder al contenido del Agregado, y todas las operaciones que se quieran hacer sobre el contenido siempre se harán a través de la entidad raíz.

·         Factoría: Crea objetos complejos (en muchos casos agregados). Crea objetos válidos (no devolverá nulos). Se parece mucho a los distintos patrones de creación de GOF.

·         Repositorio: Básicamente es el patrón DAO. Persiste entidades y agregados, no Value Objects (Los Value Object se persisten al persistir el Agregado correspondiente). La interfaz está en el dominio pero la implementación esta en la capa de infraestructura. Es muy importante el ver como en DDD hay que ser muy consciente de que los objetos es necesario guardarlos en algún sitio, y por ello la interfaz del repositorio está dentro del dominio.

·         Módulos: Paquetes, namespaces, ... Lo importante es que tienen que formar parte del lenguaje ubícuo (agrupación lógica). Es decir no tiene sentido hacer un módulo con todas las entidades, otro módulo con todos los repositorios, ...

·         Modelos anémicos. DDD no habla expresamente de modelos anémicos, pero sí lo hace de modelos “ricos” que sería el opuesto. Lo que está claro es que DDD intenta centrarse en el modelo de dominio para precisamente crear modelos ricos y evitar los modelos anémicos.

Conclusión

DDD no es una método, ni una técnica, ni una tecnología. Podríamos decir que es simplemente un conjunto de buenas prácticas especialmente pensadas para lidiar con dominios complejos o múltiples dominios, de forma que estas prácticas nos guíen en la toma de decisiones para elaborar nuestro diseño.