domain-driven-design - que - domain driven design pdf
¿Alguien puede explicar el diseño impulsado por el dominio(DDD) en inglés simple por favor? (2)
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 descubrir qué es en realidad y cómo implementarlo al crear 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 la DDD solo está destinada 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 real. Al usar DDD, debe trabajar estrechamente con un experto en dominios que pueda 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 de dominio podría ser un corredor de apuestas experimentado.
Entre usted y el experto en dominios, construye un lenguaje ubicuo (UL), que es básicamente una descripción conceptual del sistema. La idea es que usted debe poder escribir lo que hace el sistema de manera que el experto del 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 deberían 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 del 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 una ''Orden'' a la que pertenecer, por lo que decimos que la Orden es la raíz agregada, y los objetos de la Línea de pedido solo se pueden manipular mediante métodos en el objeto Pedido
DDD también recomienda varios patrones:
- Repository , un patrón para la persistencia (guardar y cargar sus datos, por lo general 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
Ahora, en este punto, tengo que decir que si no has oído hablar 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 de la empresa . Conocer esto hace que la 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 puede encontrar charlas sobre DDD).
Tome 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 problemático, 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 .