Trampas del diseño impulsado por el dominio (DDD)

Uno de los mayores escollos es que terminas con un llamado modelo anémico donde tus entidades son principalmente solo portadoras de datos y no contienen lógica de negocios. Esta situación a menudo surge cuando construye su modelo de dominio sobre un modelo de datos relacional existente y simplemente hace que cada tabla en la base de datos sea una entidad en su modelo de dominio.

Usted podría disfrutar presentación de Greg Young acerca de por qué DDD falla.

En breve:

• Falta de intención
• Modelo de Dominio Anémico
• DDD-Lite
• Falta de aislamiento
• Ubicuo qué?
• Falta de refinamiento
• Experto en Dominios proxy (Analista de negocios)

No usar contextos delimitados lo suficiente. Está hacia la parte posterior del gran libro azul, pero Eric Evans ha dejado constancia de que cree que los contextos limitados y el lenguaje ubicuo son los conceptos más importantes.

Del mismo modo, las personas tienden a centrarse demasiado en los patrones. Eso no es la carne de DDD.

Además, si no tiene mucho acceso a expertos en dominios, probablemente no esté haciendo DDD, en el mejor de los casos, es DDDish.

Más concretamente, si terminas con relaciones de muchos a muchos, probablemente has diseñado algo mal y necesitas reevaluar tus raíces/contextos agregados

Solo añadiendo a lo que otros ya han dicho; Mi experiencia personal es que las personas a menudo terminan con un modelo anémico y un modelo único en lugar de múltiples modelos específicos del contexto.

Otro problema es que muchos se centran más en la infraestructura y los patrones utilizados en DDD. Solo porque tengas entidades y repositorios y estés usando (n) Hubernate no significa que estés haciendo DDD.

No es de mi experiencia personal con el sujeto, pero se mencionó un par de veces en libros DDD y es en lo que he estado pensando recientemente: use Entidades cuando realmente necesita identidad, en otros casos use Valor Objeto. Es decir, patrón de entidad a menudo pasa a ser la opción predeterminada para cualquier sustantivo de modelo, y no es la forma en que debería ser.

Cuidado con el Gran Bola de Barro.

Uno de los escollos del diseño basado en dominios es introducir ambigüedad en un modelo. Como se explica en el artículo Diseño Estratégico Impulsado por el Dominio con Mapeo de Contexto:

La ambigüedad es el super-villano de nuestra Lenguaje ubicuo

Esto puede suceder cuando dos conceptos distintos comparten el mismo nombre, o cuando el mismo concepto puede tener diferentes usos. Puede ser necesario a

Exponer la estructura del dominio en términos de contextos acotados en un contexto mapa

Si un modelo se usa de muchas maneras diferentes, o tiene demasiadas responsabilidades, puede ser una señal de que debe dividirse.