Reunión Madrid Ágil 02-11-2010: DDD (Domain Driven Design)

1
9324

Creación: 03-11-2010

Índice de contenidos

1.Introducción
2.DDD (Domain Driven Design)
3.Conclusiones
4. Sobre el autor


1. Introducción

El 03-10-2010 tuvo lugar una de las reuniones de Madrid Ágil, en la que se habló de DDD (Domain Driven Design). En esta reunión también se tenía que haber hablado de BDD y de TDD, pero estos temas quedaron marginados y relegados a otra próxima reunión ya que
Alfredo Casado (@AlfredoCasado) se curr&oacute una presentación impresionante de DDD con ejemplo de código incluido!!! Y estuvimos liados con esto durante toda la reunión, que por cierto, fue muy muy muy interesante.

En este artículo voy a contar mis impresiones después de la reunión.


2. DDD (Domain Driven Design)

Bueno y qu&eacute es eso del “Domain Driven Design”. Una traducción más o menos literal podría ser “Diseño Dirigido por el Dominio”, pero ¿y esto qué es?

El termino viene acuñado por Eric Evans en su libro de igual nombre.

Lo que nos ha quedado claro que es 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.

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 de tu 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 técnico tiene que picar. No hay gente que sólo pinte y no hay gente que sólo codifique, todo el mundo participa en todo.
  • Cuando escribes código estás participando 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 estamos tratando. En el ejemplo que preparó Alfredo teníamos al “Alumno”.
  • 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. En el ejemplo de Alfredo eran los “DatosDeContacto” del “Alumno”.
  • 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. En el
    ejemplo de Alfredo el “Alumno” es la entidad raíz, y esta contienen a los “DatosDeContacto”.
  • 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&iacute 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.

3. Conclusiones

La reunión de ayer fue realmente muy interesante. Está claro que DDD es algo que hay que tener muy presente si queremos hacer sistemas que se puedan mantener y evolucionar en el futuro. En este artículo no hemos hecho más que rascar un poquito los principios de DDD, y por eso recomiendo leer el libro y en general toda la información que
podáis encontrar sobre el tema.

4. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

http://www.autentia.com

 

Alejandro es socio fundador de Autentia y nuestro experto en Java EE, Linux y optimización de aplicaciones empresariales. Ingeniero en Informática y Certified ScrumMaster. Seguir @alejandropgarci Si te gusta lo que ves, puedes contratarle para darte ayuda con soporte experto, impartir cursos presenciales en tu empresa o para que realicemos tus proyectos como factoría (Madrid). Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación.

1 COMENTARIO

  1. Hola, Alejandro. Lástima que no pude estar esta vez. Dos cosillas:

    1) En tu opinión, ¿se hizo suficiente hincapié en la importancia del lenguaje ubícuo? Yo creo que es, probablemente, la aportación más importante que hace DDD al desarrollo de software.

    2) Hay un grupo sobre DDD en español que no tiene ninguna actividad, pero que a buen seguro que podríamos reactivar si hay gente interesada en compartir sobre el tema: https://groups.google.com/group/ddd-es

    Un saludo,
    JMB

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad