¿Qué es el diseño controlado por dominio (DDD)? [cerrado]

276

Sigo viendo que DDD (diseño controlado por dominio) se usa mucho en los artículos: he leído la entrada de Wikipedia sobre DDD, pero todavía no puedo entender qué es realmente y cómo implementarlo para crear mis sitios.

leen3o
fuente

Respuestas:

595

En primer lugar, si no sabe que lo necesita, es posible que no lo necesite. Si no reconoce los problemas que resuelve DDD, entonces tal vez no tenga esos problemas. Incluso los defensores de DDD con frecuencia señalarán que DDD solo está destinado a proyectos grandes (> 6 meses).

Asumiendo que todavía estás leyendo en este punto, mi opinión sobre DDD es esta:

DDD se trata de tratar de hacer que su software sea un modelo de un sistema o proceso del mundo real. Al usar DDD, debe trabajar en estrecha colaboración con un experto en dominios que puede explicar cómo funciona el sistema del mundo real. Por ejemplo, si está desarrollando un sistema que maneja la colocación de apuestas en carreras de caballos, su experto en dominios podría ser un corredor de apuestas experimentado.

Entre usted y el experto en dominio, crea un lenguaje ubicuo (UL), que es básicamente una descripción conceptual del sistema. La idea es que pueda escribir lo que hace el sistema de manera que el experto en el dominio pueda leerlo y verificar que sea correcto. En nuestro ejemplo de apuestas, el lenguaje omnipresente incluiría la definición de palabras como "raza", "apuesta", "probabilidades", etc.

Los conceptos descritos por UL formarán la base de su diseño orientado a objetos. DDD proporciona una guía clara sobre cómo deben interactuar sus objetos y lo ayuda a dividir sus objetos en las siguientes categorías:

  • Objetos de valor, que representan un valor que puede tener subpartes (por ejemplo, una fecha puede tener un día, mes y año)
  • Entidades, que son objetos con identidad . Por ejemplo, cada objeto Cliente tiene su propia identidad, por lo que sabemos que dos clientes con el mismo nombre no son el mismo cliente.
  • Las raíces agregadas son objetos que poseen otros objetos. Este es un concepto complejo y funciona sobre la base de que hay algunos objetos que no tienen sentido a menos que tengan un propietario. Por ejemplo, un objeto 'Línea de pedido' no tiene sentido sin que pertenezca un 'Pedido', por lo que decimos que el Pedido es la raíz agregada, y los objetos de Línea de pedido solo pueden manipularse mediante métodos en el objeto Pedido

DDD también recomienda varios patrones:

  • Repositorio , un patrón de persistencia (guardar y cargar sus datos, generalmente a / desde una base de datos)
  • Factory , un patrón para la creación de objetos.
  • Servicio, un patrón para crear objetos que manipulan los objetos de su dominio principal sin ser parte del dominio.

Ahora, en este punto, tengo que decir que si no has oído hablar de ninguna de estas cosas antes, no deberías tratar de usar DDD en ningún proyecto para el que tengas una fecha límite. Antes de intentar DDD, debe estar familiarizado con los patrones de diseño y los patrones de diseño empresarial . Saber esto hace que DDD sea mucho más fácil de entender. Y, como se mencionó anteriormente, hay una introducción gratuita a DDD disponible en InfoQ (donde también puede encontrar charlas sobre DDD).

Rob Knight
fuente
33
Wow ... ¡Qué gran respuesta! Muy apreciado y la mejor explicación que he leído en cualquier lugar por una milla. Gracias. Descargaré ese libro mañana.
leen3o
3
"Las raíces agregadas son objetos que poseen otros objetos. Este es un concepto complejo y funciona sobre la base de que hay algunos objetos que no tienen sentido a menos que tengan un propietario". Creo que podría ser una idea errónea aquí, la idea que mencionas es "Valor total", mientras que Aggregate está más preocupado por el Límite de la transacción, donde todas las reglas invariables de negocios deben aplicarse aquí.
super1ha1
66
Para ser honesto, esto suena como casi todos los proyectos donde los desarrolladores colaboran con arquitectos durante más de un mes. (Bueno, de acuerdo con mi experiencia al menos). Esta comprensión me hace apreciar aún más su respuesta. :)
Jaroslav Záruba
44
No estoy de acuerdo con la afirmación de que DDD "solo está destinado a proyectos grandes". DDD no es nada que deba hacer completamente o no hacer nada. Puedes hacer algunas prácticas desde DDD. Por ejemplo, puede hacer "Objetos de valor" y "lenguaje ubicuo" y no hacer raíces agregadas en un proyecto pequeño.
EasterBunnyBugSmasher
66
Por cierto, ¿no hacemos análisis de dominio para cada proyecto que hacemos o modelamos? ¿No tenemos conversaciones interminables como BA con clientes y pymes para comprender el dominio y el alcance del proyecto? Todavía no entiendo lo que es extraordinariamente sobresaliente en DDD, ¿entonces algún otro proyecto de desarrollo de software?
supernova
51

Tome StackOverflow como ejemplo. En lugar de comenzar a diseñar algunos formularios web, primero se concentra en hacer modelos orientados a objetos de las entidades dentro de su dominio del problema, por ejemplo, Usuarios, Preguntas, Respuestas, Votos, Comentarios, etc. Dado que el diseño se basa en los detalles del problema dominio se llama diseño impulsado por dominio .

Puedes leer más en el libro de Eric Evans .

Matt Howells
fuente
55
Hay una versión corta del libro de Eric Evans disponible de forma gratuita .
troelskn 03 de
¡El problema es que necesitas a alguien que entienda el dominio de una manera lo suficientemente abstructiva como para que pueda decir algo útil antes de que hayan vinculado las páginas web! Cuando este es el caso más grande!
Ian Ringrose
3
Pero, ¿quién comenzaría diseñando el formulario, sinceramente? Cualquier curso académico respetable pasaría por aplicaciones de análisis, diseño y modelado de acuerdo con los requisitos del negocio. Simplemente no entiendo qué hay de nuevo con esta técnica.
Sebas
66
Yo también, esto es simplemente un diseño orientado a objetos, utilizado por todos incluso antes de que surgiera este concepto. No veo ningún invento nuevo aquí.
Ronen Festinger
2
@RonenFestinger, no juzgues a DDD solo por esta respuesta. Hay muchas ideas en el libro de Eric Evans. Por ejemplo, contextos limitados. El paradigma de contexto acotado es uno de los pilares de los microservicios que estamos construyendo hoy. Leer el libro también te ayuda a comprender los microservicios.
Kerem Baydogan el