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

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.

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).

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 .