Así que recibí esta pregunta de uno de los desarrolladores en mi equipo: ¿Qué es el diseño impulsado por el dominio? Por supuesto, podría señalar el libro de Evans, pero ¿es realmente una respuesta?¿Qué es el diseño impulsado por dominio?
¿Cómo explicarías DDD en unas pocas frases a los ingenieros de software junior en tu equipo?
Yo diría que esta práctica promueve la concentración de sus esfuerzos en el "espacio problemático" en lugar de en el "espacio de soluciones". Conducir una solución emergente (el diseño) mediante el estudio y realmente conocer y comprender el dominio. Una de las prácticas (tomada de XP) sería la escritura de historias que ocurren en el dominio del problema. A partir de estos, puede identificar sus casos de uso y objetos para su diseño. Ellos 'emergen' y le dicen lo que debe ser la solución y cómo deberán interactuar entre ellos.
Una parte importante de DDD es el llamado lenguaje omnipresente; es decir, hablan el mismo idioma que los expertos en negocios. Y cree su código/arquitectura para que refleje este lenguaje para evitar problemas de impedancia.
Hasta donde yo lo entiendo, no es el lenguaje de los programadores que hablan el dominio de los expertos, sino el desarrollo de un lenguaje común. – sumek
@sumek tratando de hacer que las personas acuerden un * idioma común * probablemente no valga la pena. Lleva mucho tiempo conseguir que un negocio acepte ** cualquier cosa **. En mi experiencia, generalmente es mejor ajustarse a la jerga existente, es decir, si quieres enviar a tiempo ... – MattDavey
En el proceso de descubrir el "dominio", usted forma un lenguaje común, que tanto los desarrolladores como todos los demás interesados en el proyecto entienden.
El modelo de dominio y su "jerga" es bastante observable en el código fuente para el producto final. Esa es al menos mi experiencia
Tratando de entender de qué se trata el software que está escribiendo y reflejando esa comprensión en el modelo.
InfoQ tienen un libro electrónico gratuito:
Es una buena lectura con un montón de ejemplos.
Es muy bueno y conciso. Los nuevos desarrolladores de nuestro equipo tienen que leerlo hoy en día. – Hace
El diseño controlado por el dominio se trata de administrar la complejidad de una aplicación en el modelo de dominio donde puede destilarse con mayor facilidad.
Es muy difícil de describir en algunas frases, pero recomendaría el libro InfoQ como una buena introducción. También he escuchado que mucha gente está haciendo un club de lectura con el libro DDD de Evans, lo que ha ayudado mucho a entenderlo.
DDD ha avanzado mucho desde que se escribió el libro azul hace 10 años. En aquel entonces, un modelo de dominio enriquecido era realmente la única forma de capturar la complejidad del negocio de forma cohesiva. En estos días tenemos algunas opciones más, como CQRS y aprovisionamiento de eventos, por lo que la vieja noción de que 'DDD == modelo de dominio enriquecido' no es cierto. Aprecio que esta respuesta en sí fue escrita hace 5 años. – MattDavey
Para mí es el siguiente nivel de OOD/OOP donde la encapsulación se trata del espacio problemático, tal como lo describen y entienden los usuarios, y no tanto de la implementación técnica.
Lea "An Introduction to Domain Driven Design" para una introducción rápida pero detallada a DDD
> Moderador nota: Enlace ya no sea relevante Visita [http://dddcommunity.org] (http://dddcommunity.org/)/ – cvs