DISCLAIMER: ESTE ARTÍCULO TODAVÍA ESTÁ EN CONSTRUCCIÓN
Como otros resúmenes de libros que he hecho, éste es un intento de clarificar las ideas sobre el libro que estoy actualmente leyendo, Domain-Driven Design: Tackling Complexity in the Heart of Software. No aporto nada nuevo, se trata simplemente de tratar de explicar con mis propias palabras lo leído de forma resumida.
Introducción
El Diseño Guiado por el Dominio (DDD) es un enfoque de diseño de software que enlaza el modelado del dominio y el diseño del software, con el objetivo de crear un modelo del dominio rico que evolucione a través de sucesivas iteraciones del diseño. En muchos proyectos la mayor complejidad es debida al dominio del problema, y es ésta complejidad la que trata de atajar DDD, partiendo de las premisas de que el foco principal del proyecto está sobre el dominio y que el diseño de un dominio complejo se basa en un modelo. DDD está orientado a las metodologías ágiles y supone que el desarrollo es iterativo y que existe una estrecha relación entre los desarrolladores y los expertos del dominio.
Parte I : Poniendo el Modelo del Dominio a Trabajar
Se presentan los objetivos del DDD.
- 1 - Triturando el Conocimiento: La experimentación usando un lenguaje basado en el modelo y el ciclo de realimentación que se obtiene a través de la implementación hace posible encontrar un modelo rico y destilarlo. Esto convierte el conocimiento del equipo en un modelo valioso.
- 2 - Comunicación y Uso del Lenguaje: Se debe usar el modelo como base del lenguaje que desarrolladores y expertos de negocio usan día a día, tanto para comunicarse entre ellos como en el código. Este LENGUAJE UBICUO evita tener que traducir entre el lenguaje de unos y otros, aunque cada grupo puede extenderlo con términos propios de su ámbito que no afectan al otro grupo. De esta manera los modelos serán explicativos y se podrán usar sin problemas en las discusiones entre ambos grupos.
- 3 - Enlazando el Modelo y la Implementación: Si el diseño no está alineado con el modelo es difícil determinar si el software es correcto y es imposible llevar a cabo cambios en el diseño. Se debe buscar un modelo que se pueda implementar, para lo que se necesitan herramientas y lenguajes que soporten un paradigma de modelado, como la programación orientada a objetos.
Parte II: Las Piezas de un Diseño Guiado por el Modelo
Se condensa un núcleo de buenas prácticas del modelado orientado a objetos de dominios, que establecerán el conjunto de piezas del DDD, permitiendo dar orden al modelo y entender el trabajo entre desarrolladores mediante el uso de un lenguaje común. Se hace hincapié en la necesidad de mantener el modelo y la implementación alineados.
- 4 - Aislando el Dominio: El software que resuelve los problemas del dominio constituye sólo una pequeña parte del sistema, aunque su importancia es inmensa. Es necesario desacoplar el modelo de las demás funciones para evitar la confusión con otros conceptos más tecnológicos. Una buena idea para ello es usar una ARQUITECTURA EN CAPAS.
- 5 - Un Modelo Expresado Mediante Software: En primer lugar, se revisan las asociaciones en el modelo. Se debe definir la dirección en la que deben ser recorridas, tratar de incluir un calificador para reducir la multiplicidad y eliminar las asociaciones que no sean necesarias. Después se revisan los tres patrones de elementos del modelo: ENTIDADES (objetos que poseen una identidad propia que se debe preservar), OBJETOS DE VALOR (objetos que no tienen identidad y que describen alguna característica de algo) y SERVICIOS (operaciones que conceptualmente no pertenecen a ningún objeto). Estos elementos del modelo se pueden agrupar en MÓDULOS, que deben contener conceptos con gran cohesión entre ellos y permiten deben tener un bajo acoplamiento con otros MÓDULOS para facilitar la comprensión del sistema.
- 6 - El Ciclo de Vida de un Objeto de Dominio: Algunos objetos son creados, usados en alguna computación y destruidos. Otros viven por más tiempo y no siempre en memoria, también pueden ser almacenados en una base de datos, por ejemplo. Los objetos tienen dependencias con otros y cambian de estado debiendo mantener ciertas condiciones. Existen ciertos patrones que ayudan a gestionar el ciclo de vida de un objeto. Un AGREGADO en un grupo de ENTIDADES y OBJETOS DE VALOR sobre el que se deben mantener ciertas condiciones, con una ENTIDAD como raíz que será la única a la que puedan acceder otros objetos externos. Las FACTORÍAS encapsulan la creación de un objeto o un AGREGADO. Los REPOSITORIOS permiten recuperar la ENTIDAD raíz de un AGREGADO proveyendo un punto de entrada para acceder a un objeto durante su ciclo de vida.
- 7 - Usando el Lenguaje: Un Ejemplo Extendido: Ejemplo del diseño de un sistema de transporte de carga poniendo en práctica los patrones expuestos en los capítulos anteriores.
Parte III: Refactorizando hacia un Conocimiento más Profundo
Se va más allá de las piezas del DDD para afrontar el reto de montar con ellas modelos que supongan una ventaja. Se revisa el proceso de descubrimiento del modelo y su transformación paulatina a medida que se gana nuevo conocimiento sobre el mismo.
- 8 - Un Avance Significativo: A medida que se asimila el conocimiento emergen gradualmente modelos más profundos a través de pequeñas refactorizaciones. A veces, el modelo se va clarificando hasta dar lugar a modelos mucho más profundos que dan una visión más clara del sistema. Esta oportunidad hay que aprovecharla cuando sea posible y conviene estar preparado para ello, haciendo explícitos los conceptos del sistema, procurando tener un diseño adaptable en todo momento y destilando el modelo.
- 9 - Haciendo Explícitos los Conceptos Implícitos: Muchas transformaciones de los modelos ocurren cuando se reconoce un concepto que se ha dado a entender en una conversación o que está presente de forma implícita en el diseño, y se representa de forma explícita en el modelo. Para buscar estos conceptos hay que escuchar el lenguaje que se usa, buscar en los puntos de mayor complicación en el modelo y las contradicciones del modelo, leer sobre el negocio del dominio y probar diferentes posibilidades. Algunos conceptos que son menos obvios son las restricciones, los procesos que pueden ser expresados como SERVICIOS, y las reglas de negocio que se deben cumplir que se pueden encapsular mediante ESPECIFICACIONES.
- 10 - Diseño Adaptable: El software debe servir tanto a los usuarios como a los propios desarrolladores, que deben ser capaces de hacer evolucionar el código. Para ello es necesario un diseño adaptable que facilite el cambio. Para ello el modelo se debe expresar a través de INTERFACES QUE REVELEN SU PROPÓSITO usando términos del LENGUAJE UBICUO. Estos interfaces deben usar FUNCIONES SIN EFECTOS SECUNDARIOS o, en su defecto utilizar ASERCIONES que expongan cuáles son sus efectos secundarios. También se debe simplificar su interpretación a través de la CLAUSURA DE OPERACIONES, haciendo que las operaciones devuelvan objetos del mismo tipo que sus parámetros. Conviene mantener un mismo NIVEL CONCEPTUAL en cuanto a los elementos del sistema y tratar de utilizar CLASES AUTÓNOMAS dentro de lo posible.
- 11 - Aplicando Patrones de Análisis: Un patrón de análisis puede servir como guía para la investigación del modelo, aunque no suelen ser aplicables tal cual, sino que deben ser adaptados. Sin embargo, permiten ahorrar tiempo en la investigación del modelo.
- 12 - Relacionando Patrones de Diseño con el Modelo: Algunos patrones de diseño pueden usar como patrones de dominio, ya que sus elementos se corresponden con conceptos generales que emergen en muchos dominios. Es el caso, por ejemplo, de los patrones ESTRATEGIA o POLÍTICA y COMPUESTO.
Parte IV: Diseño Estratégico
Se tratan los problemas que pueden aparecer en sistemas complejos, organizaciones grandes e interacciones con otros sistemas. El diseño estratégico permite llevar a cabo a gran escala los objetivos establecidos en la primera parte del libro.
- 14: Manteniendo la Integridad del Modelo
- 15: Destilación
- 16: Estructuras de Gran Escala
- 17: Reunificando la Estrategia
Conclusion
…
Referencias:
, Eric Evans