¿Qué es el diseño basado en dominios (DDD)? [cerrado]
Sigo viendo que DDD (Domain Driven Design) 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 lo implementaría en la creación de mis sitios.
En primer lugar, si no sabes que lo necesitas, es posible que no lo necesites. Si no reconoce los problemas que resuelve DDD, entonces tal vez no tenga esos problemas. Incluso los defensores de DDD señalarán con frecuencia que DDD sólo está destinado a proyectos grandes (>6 meses).
Suponiendo que todavía estés leyendo en este punto, mi opinión sobre DDD es la siguiente:
DDD consiste en intentar hacer de su software un modelo de un sistema o proceso del mundo real. Al utilizar DDD, debe trabajar en estrecha colaboración con un experto en el dominio que pueda explicar cómo funciona el sistema del mundo real. Por ejemplo, si está desarrollando un sistema que maneja la realización de apuestas en carreras de caballos, su experto en el dominio podría ser un corredor de apuestas experimentado.
Entre usted y el experto en el dominio, construye un lenguaje ubicuo (UL), que es básicamente una descripción conceptual del sistema. La idea es que puedas escribir lo que hace el sistema de manera que el experto en el dominio pueda leerlo y verificar que es correcto. En nuestro ejemplo de apuestas, el lenguaje omnipresente incluiría la definición de palabras como "carrera", "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 le ayuda a dividirlos 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 dueño. Por ejemplo, un objeto 'Línea de pedido' no tiene sentido sin un 'Orden' al que pertenecer, por lo que decimos que el Orden es la raíz agregada, y los objetos Línea de pedido solo se pueden manipular mediante métodos en el objeto Orden.
DDD también recomienda varios patrones:
- Repositorio , un patrón para la persistencia (guardar y cargar sus datos, generalmente hacia/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 intentar 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 realizar un modelado orientado a objetos de las entidades dentro del dominio de su problema, por ejemplo Usuarios, Preguntas, Respuestas, Votos, Comentarios, etc. Dado que el diseño está impulsado por los detalles del problema. dominio se llama diseño impulsado por dominio .
Puedes leer más en el libro de Eric Evans .
