design patterns - resueltos - Modelo de dominio anémico versus modelo de dominio
modelo de dominio introduccion (3)
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 se ajuste a 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 el modelo de dominio anémico anti-patrón. Sin embargo, si usa un DB relacional, no hay forma de evitar seleccionar la parte que hace que 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. No dude en pedir una aclaración.
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 forma 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, y en algunos casos se necesita un verdadero esfuerzo para apartarse de este punto de vista).
Dos temas de interés vienen a mi mente:
- Los objetos de transferencia de datos (DTO) son diferentes de los objetos de dominio. Sirven para diferentes propósitos en diferentes lugares en una arquitectura, no los confundan. 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 dirigidos a sistemas automatizados en lugar de usuarios.
- Esfuércese después de seleccionar un ORM que le permita emplear la ignorancia de persistencia . Esto significa que puede definir su modelo de dominio de forma ilimitada y simplemente hacer que ORM asigne los objetos a una base de datos relacional.
Se convierte en un modelo de dominio "real" cuando contiene todo (o la mayoría) del comportamiento que conforma el dominio de negocios (tenga en cuenta que estoy enfatizando la lógica de negocios , no la UI u otras preocupaciones ortogonales).
Si está utilizando el lenguaje ubicuo y obtiene comentarios constantes de los expertos de su dominio , sabrá que está en el camino correcto (los expertos deberían asentir cuando ven el modelo de su dominio). Si no estás haciendo estas cosas, no estás haciendo DDD ( Eric Evans habla de ello ).
En 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 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 los datos y la persistencia lo distraiga del verdadero modelado de dominios ...