modelo de dominio anémico vs modelo de dominio

Question

Volver a estar confundido después de leer acerca de este antipatrón y las muchas inquietudes al respecto aquí en SO.

Si tengo un modelo de dominio y capturo los datos que deben persistir en un objeto de transferencia de datos, ¿eso hace que mi modelo de dominio sea un envoltorio alrededor de los datos? En ese caso estaría usando un modelo de dominio anémico. Pero si agrego suficiente lógica de dominio en ese contenedor, ¿en qué momento se convierte en un modelo de dominio real?

Me da la impresión de que capturar lo que debe persistir en un modelo de dominio viola las buenas prácticas y crea un anti-patrón de modelo de dominio anémico. Sin embargo, si utiliza una base de datos relacional, no hay forma de evitar seleccionar la parte que crea el estado del objeto y guardarlo.

Como estoy bastante confundido acerca de los conceptos, no estoy seguro de que lo que escribo tenga sentido. No dude en pedir una aclaración.

Answer 1

Se convierte en un modelo de dominio 'real' cuando contiene todos (o la mayoría) del comportamiento que conforma el dominio comercial (tenga en cuenta que estoy haciendo hincapié en Lógica de negocios , no UI u otras preocupaciones ortogonales).

Si está utilizando el Idioma ubicuo y obtiene comentarios constantes de sus expertos en dominios , sabrá que en el camino correcto (los expertos deben asentir cuando ven el modelo de su dominio). Si no está haciendo estas cosas, no está haciendo DDD ( Eric Evans habla al respecto ).

Sobre el punto de los DTO: no los ignore. Desde la perspectiva de la implementación, los necesitará para transportar datos entre capas / niveles. La forma en que combine los DTO y los verdaderos objetos de dominio realmente depende de la tecnología que esté utilizando.

Como se mencionó en una respuesta anterior, tal vez su enfoque en datos y persistencia lo está distrayendo del modelado de dominio verdadero ...

Answer 2

Me vienen a la mente dos elementos de interés:

• Los objetos de transferencia de datos (DTO) son diferentes de los objetos de dominio. Sirven para diferentes propósitos en diferentes lugares de una arquitectura, no los confunda. Los objetos de dominio proporcionan una API rica con alta cohesión . Los DTO son estructuras de datos pasivos que se utilizan en la interfaz externa de una aplicación, como UI ViewModels, pero están dirigidos a sistemas automatizados en lugar de usuarios.
• Esforzarse después de seleccionar un ORM que le permita emplear Ignorancia de persistencia . Esto significa que puede definir su modelo de dominio de forma ilimitada y simplemente hacer que el ORM asigne los objetos a una base de datos relacional.

Answer 3

  

Pero si agrego suficiente lógica de dominio en ese contenedor, ¿en qué momento se convierte en un modelo de dominio real?

Llegar al modelo de dominio mediante la adición de elementos de una manera aleatoria es posible, pero ciertamente no es un diseño impulsado por el dominio. (Sé que esto no es realmente útil. Tiendo a pensar muy centrado en los datos yo mismo, y en algunos casos se necesita un esfuerzo real para alejarse de este punto de vista).