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.
