modelo de dominio anémico versus modelo de dominio

Question

Estar confundido de nuevo después de leer sobre este antipatrón y las muchas preocupaciones al respecto aquí en SO.

Si tengo un modelo de dominio y capturo los datos que deben conservarse 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 infringe las buenas prácticas y crea el anti-patrón del modelo de dominio anémico. Sin embargo, si usa una base de datos relacional, no hay forma de evitar seleccionar la parte que crea el estado del objeto y guardarlo.

Dado que estoy bastante confundido acerca de los conceptos, no estoy seguro de que lo que escribo tenga sentido. Siéntase libre de pedir aclaraciones.

Answer 1

se convierte en un modelo de dominio 'real' cuando contiene todos (o la mayoría) de la conducta que conforma el dominio de negocio (Nota que estoy haciendo hincapié en la lógica de negocio , no la interfaz de usuario u otro preocupaciones ortogonales).

Si está utilizando el Lenguaje Ubicuo , y obtener una retroalimentación constante de sus expertos en el dominio , usted sabrá que usted está en el camino correcto (expertos deben asentir cuando ven su modelo de dominio) Si no estás haciendo estas cosas, no estás haciendo DDD (Eric Evans speak about it).

En el punto de los DTO: no los ignore. Desde una perspectiva de 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 alude en una respuesta anterior, tal vez su enfoque en los datos y persistencia le está distrayendo de cierto modelado de dominio ...

Answer 2

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

Llegar al modelo de dominio mediante la adición de cosas de manera fortuita 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, y en algunos casos se necesita un esfuerzo real para salir de este punto de vista.)

Answer 3

Me vienen a la mente dos artículos de interés:

• Los objetos de transferencia de datos (DTO) son diferentes de los objetos de dominio. Sirven propósitos diferentes en diferentes lugares de una arquitectura, no los confundas. Los objetos de dominio proporcionan API rica con alta cohesión. Los DTO son estructuras de datos pasivos utilizados en la interfaz externa de una aplicación, bastante parecidos a los UI ViewModels, pero destinados a sistemas automatizados en lugar de a usuarios.
• Esfuércese después de seleccionar un ORM que le permita emplear Ignorancia de persistencia. Esto significa que puede definir su Modelo de Dominio de una manera ilimitada, y simplemente hacer que el ORM asigne los objetos a una base de datos relacional.