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.
