Escuché sobre el desarrollo impulsado por dominio de un desarrollador en el área. Lo habló como si se tratara de la bala de plata a los requisitos cambiantes.
He leído el wiki . Todavía no está muy claro. ¿Qué es "3D" en términos prácticos? ¿Es realmente tan sorprendente que ahora los diagramas de clase UML sean obsoletos?
Respuestas:
Bueno, antes que nada, no creo que el artículo de Wikipedia al que te refieras sea muy bueno, principalmente porque hace referencia a un montón de cosas que solo son auxiliares del diseño impulsado por dominio y hace poco para iluminar a alguien sobre la práctica.
Pero, como alguien que se ha tomado en serio el diseño impulsado por el dominio (que generalmente es DDD, en lugar de 3D, por lo que vale), siempre sentí que los fundamentos de DDD son obvios, si lees tanto como el primer capítulo de Eric El libro de Evans. Pero es un conjunto de patrones y prácticas, por lo que no es tan fácil dar un resumen de 3 oraciones de lo que es y cuáles son las ventajas sin entrar en detalles. Los detalles que resuenan con cualquier persona también pueden ser muy diferentes; Es probable que hace 10 años no hubiera visto el punto en absoluto.
DDD no es una bala de plata. Cuando se hace con sensatez, se trata de adoptar un enfoque artesanal para crear software y reconocer la necesidad de reducir la fricción cognitiva entre los equipos de desarrollo y las empresas para las que están creando software. Una de las prácticas más importantes es tener una capa en la que el vocabulario de dominio utilizado por el equipo de software y el equipo de negocios coincida lo más posible. Construye esta capa de forma iterativa a medida que comprende el problema comercial que está tratando de resolver. Cuando la lógica de negocios se codifica de manera sensata en esta capa, aislada de todas las dependencias intrincadas que las aplicaciones empresariales suelen tener al factorizar las interacciones con esos sistemas en las interfaces, el lenguaje utilizado en la capa de dominio real finalmente se vuelve bastante conciso, obvio y legible.
Teniendo en cuenta la forma en que he visto la mayoría del software empresarial, en la práctica, DDD puede sonar como una bala de plata, porque la mayoría del software empresarial tiene una separación tan pobre de las preocupaciones que es casi inestable, y el equipo de software vive con un gran miedo al cambio porque no tienen idea de cuáles podrían ser los efectos secundarios de los cambios de código aparentemente triviales, mientras que una capa de dominio correctamente factorizada será independientemente verificable y verificable. Pero en realidad, DDD reconoce que los sistemas rara vez existen de forma aislada. DDD incluye patrones de afrontamiento para sistemas heredados (capa anticorrupción, contextos limitados, por nombrar un par).
Si practicas el diseño orientado a objetos, incluida la disciplina del acoplamiento flojo, y practicas pruebas unitarias de manera bastante religiosa, y refactorizas sin piedad el código, y trabajas con expertos en dominios mientras construyes tu sistema, esencialmente obtendrás un resultado que es básicamente de lo que hablan los defensores del diseño impulsado por dominio.
Hay algunos patrones específicos descritos en el libro de Evans que se aplican principalmente al desarrollo de software empresarial, y algunos que son principios bastante universales, pero esencialmente, DDD es un enfoque pragmático para el desarrollo de software que, con el tiempo, puede reducir la acumulación de deuda técnica, y haga que sus clientes estén más felices porque pueden hablar el mismo idioma entre ellos, y ofrecer soluciones que funcionen mejor debido a las ventajas de entenderse mejor.
Una descripción de alto nivel podría ser:
Modele sus clases para reflejar las estructuras de datos y el comportamiento de su dominio problemático.
Esto le permite asignar los cambios en su dominio problemático directamente a los cambios en su código, por lo que debería ser más fácil de actualizar a medida que evoluciona su dominio problemático.
DESCARGO DE RESPONSABILIDAD: He agregado esta respuesta después de que esta pregunta se haya marcado como duplicada. No estoy de acuerdo, pero aquí estamos. :-)
El diseño dirigido por dominio tiene como objetivo diseñar software en dominios de alto valor / alta complejidad.
Esto se convierte en un enfoque diferente para construir software empresarial: hay demasiado aprendizaje involucrado, y la consecuencia más importante es que no obtendrá la solución correcta a primera vista.
O la combinación de ambos.
En ambos sentidos, necesitará buenos fundamentos de software para reescribir software con frecuencia . Esa es la razón por la cual el libro hizo hincapié en un conjunto dado de patrones en torno al patrón del Modelo de Dominio: fueron la combinación más razonable en 2004.
Sin embargo, la POO y el patrón táctico no son lo más importante. El dominio técnico es necesario para construir un gran software de forma evolutiva. Pero es solo un ingrediente de la receta. ¿Los demás?