¿Puede Alguien Explicar Domain Driven Design (DDD) En Inglés Sencillo, Por Favor? [cerrado]

En primer lugar, si no sabes que lo necesitas, es posible que no lo necesites. Si usted no reconoce los problemas que DDD resuelve entonces tal vez usted no tiene esos problemas. Incluso los defensores de DDD con frecuencia señalan 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 trata de hacer de su software un modelo de un sistema o proceso del mundo real. Al usar DDD, usted es para trabajar estrechamente con un experto en dominios quién 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, construye un lenguaje ubicuo (UL), que es básicamente una descripción conceptual del sistema. La idea es que usted debe ser capaz de escribir lo que el sistema hace de una manera que el experto del dominio pueda leerlo y verificar que es correcto. En nuestro ejemplo de apuestas, el lenguaje ubicuo incluiría la definición de palabras como "raza", "apuesta", "probabilidades", etc.

Los conceptos descritos por la 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 le ayuda a dividir sus objetos en las siguientes categorías:

• Objetos de valor, que representan un valor que podría tienen sub-partes (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 'Order Line' no tiene sentido sin un' Orden ' al que pertenecer, por lo que decimos que el Orden es la raíz agregada, y los objetos de línea de orden solo se pueden manipular a través de métodos en el objeto de orden

DDD también recomienda varios patrones:

• Repositorio , un patrón de persistencia (guardar y cargar sus datos, típicamente 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 sus objetos de dominio principal sin ser parte del dominio en sí

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