domain-driven-design - significado - domain driven design pdf
Dificultades de diseño impulsado por dominio(DDD) (7)
Soy bastante nuevo en DDD y me gustaría saber sobre cualquier trampa que quiera compartir. Lo resumiré más adelante para que más novatos lo lean :)
Gracias
Resumen hasta ahora:
- Modelo de dominio anémico en el que sus entidades principalmente solo contienen datos y no contienen lógica empresarial
- No usar contextos limitados lo suficiente
- Centrándose demasiado en los patrones
Hay una buena presentación sobre este tema también here (video).
Cuidado con la gran bola de barro .
Uno de los escollos del diseño basado en dominios es introducir la ambigüedad en un modelo. Como se explica en el artículo Diseño de dominio dirigido por dominio con mapeo de contexto :
La ambigüedad es el súper villano de nuestro 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
exponer la estructura del dominio en términos de contextos acotados en un mapa de contexto
Si un modelo se usa de muchas maneras diferentes, o tiene demasiadas responsabilidades, puede ser una señal de que se debe dividir.
No es mi experiencia personal con el tema, pero se mencionó un par de veces en los libros de DDD y es en lo que he estado pensando recientemente: usa Entidades cuando realmente necesitas identidad, en otros casos usa Valor Objeto . Es decir, el patrón de entidad suele ser la opción predeterminada para cualquier nombre de modelo, y no es la forma en que debería ser.
No usar los contextos limitados lo suficiente. Se encuentra en la parte posterior del gran libro azul, pero Eric Evans ha dicho 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. Esos no son 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 hayas diseñado algo incorrecto y necesitas reevaluar tus raíces / contextos agregados.
Podría disfrutar la here de Greg Young sobre por qué falla la DDD.
En breve:
- Falta de intencion
- Modelo de dominio anémico
- DDD-Lite
- Falta de aislamiento
- Ubicua ¿qué?
- Falta de refinamiento
- Proxy Domain Expert (analista de negocios)
Probablemente el más importante: no asimilar el principio central y fundamental del Modelo de Dominio y su representación en el Lenguaje Ubicuo. Con la gran cantidad de opciones tecnológicas disponibles, es muy fácil para su cabeza llenar con ORM, MVC frameworks, ajax, sql vs nosql, ... Tanto que queda poco espacio para el problema real que está intentando resolver.
Y ese es el mensaje clave de DDD: no lo hagas. En su lugar, centrarse explícitamente en el espacio del problema ante todo. Cree un modelo de dominio desprovisto de desorden arquitectónico que capture, exponga y comunique el dominio.
Ah, y otro: pensar que necesita servicios de dominio para todo lo que puede hacer en el modelo de dominio. No. Siempre debe primero intentar poner la lógica del dominio con el tipo de Entidad / Valor al que pertenece. Solo debe crear servicios de dominio cuando encuentre funciones que no pertenecen naturalmente a un E / V. De lo contrario, terminas con el modelo de dominio anémico resaltado en otra parte.
hth
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 de contexto específico.
Otro problema es que muchos se centran más en la infraestructura y los patrones utilizados en DDD. El hecho de que tenga entidades y repositorios y esté utilizando (n) Hubernate no significa que esté haciendo DDD.
Uno de los mayores escollos es que terminas con un llamado modelo anémico en el que tus entidades principalmente solo contienen datos y no contienen lógica empresarial. Esta situación a menudo surge cuando construye su modelo de dominio sobre un modelo de datos relacionales existente y simplemente hace de cada tabla de la base de datos una entidad en su modelo de dominio.