Solución:
Solo piénselo de esta manera, el modelo de dominio no debe depender de nada y no debe tener código de infraestructura dentro de él. El modelo de dominio no debe ser serializable ni heredar de algunos objetos ORM o incluso compartirlos. Todos estos son problemas de infraestructura y deben definirse por separado del modelo de dominio.
Pero eso es si está buscando un DDD puro y su proyecto valora la escalabilidad y el rendimiento sobre la velocidad del desarrollo inicial. Muchas veces, mezclar las preocupaciones de infraestructura con su “modelo de dominio” puede ayudarlo a lograr grandes avances en velocidad a costa de la escalabilidad. El punto es que debe preguntarse: “¿Los beneficios del DDD puro valen la pena en la velocidad de desarrollo?”. Si su respuesta es sí, aquí está la respuesta a su pregunta.
Comencemos con un ejemplo en el que su aplicación comienza con un modelo de dominio y da la casualidad de que las tablas en la base de datos coinciden exactamente con su modelo de dominio. Ahora, su aplicación crece a pasos agigantados y comienza a experimentar problemas de rendimiento al consultar la base de datos. Ha aplicado algunos índices bien pensados, pero sus tablas están creciendo tan rápidamente que parece que necesita desnormalizar su base de datos solo para mantenerse al día. Entonces, con la ayuda de un dba, se le ocurre un nuevo diseño de base de datos que manejará sus necesidades de rendimiento, pero ahora las tablas son muy diferentes a como eran antes y ahora fragmentos de las entidades de su dominio se distribuyen en varias tablas en lugar de que ser una tabla para cada entidad.
Este es solo un ejemplo, pero demuestra por qué su modelo de dominio debe estar separado de su modelo de persistencia. En este ejemplo, no desea dividir las clases de su modelo de dominio para que coincidan con los cambios que realizó en el diseño del modelo de persistencia y esencialmente cambiar el significado de su modelo de dominio. En su lugar, desea cambiar la asignación entre su nuevo modelo de persistencia y el modelo de dominio.
Hay varios beneficios de mantener estos diseños separados, como la escalabilidad, el rendimiento y el tiempo de reacción a los cambios de emergencia de la base de datos, pero debe compararlos con el costo y la velocidad del desarrollo inicial. Generalmente, los proyectos que se beneficiarán al máximo de este nivel de separación son las aplicaciones empresariales a gran escala.
ACTUALIZACIÓN PARA COMENTARIOS
En el mundo del desarrollo de software, existe una enésima cantidad de posibles soluciones. Debido a esto, existe una relación inversa indirecta entre la flexibilidad y la velocidad inicial de desarrollo. Como ejemplo simple, podría codificar lógica en una clase o podría escribir una clase que permita que se le pasen reglas de lógica dinámica. La primera opción tendría una mayor velocidad de desarrollo, pero al precio de un menor grado de flexibilidad. La última opción tendría un mayor grado de flexibilidad, pero a costa de una menor velocidad de desarrollo. Esto es cierto en todos los lenguajes de codificación porque siempre hay un número enésimo de posibles soluciones.
Hay muchas herramientas disponibles que lo ayudan a aumentar la velocidad y la flexibilidad de desarrollo inicial. Por ejemplo, una herramienta ORM puede aumentar la velocidad de desarrollo de su código de acceso a la base de datos al mismo tiempo que le brinda la flexibilidad de elegir cualquier implementación de base de datos específica que admita ORM. Desde su perspectiva, esta es una ganancia neta tanto en tiempo como en flexibilidad menos el costo de la herramienta (algunas de las cuales son gratuitas) que puede o no valer la pena para usted según el costo del tiempo de desarrollo en relación con el valor de la herramienta. necesidad de Negocios.
Pero, para esta conversación sobre estilos de codificación, que es esencialmente lo que es el diseño controlado por dominio, debe tener en cuenta el tiempo que tomó escribir la herramienta que está utilizando. Si tuviera que escribir esa herramienta ORM o incluso escribir la lógica de acceso a la base de datos de tal manera que admita todas las implementaciones que le brinda la herramienta, tomaría mucho más tiempo que si solo tuviera que codificar la implementación específica que planea. sobre el uso.
En resumen, las herramientas pueden ayudarlo a compensar su propio tiempo de producción y el precio de la flexibilidad, a menudo distribuyendo el costo de ese tiempo a todos los que compran la herramienta. Pero, cualquier código, incluido el código que utiliza una herramienta, seguirá afectado por la relación velocidad / flexibilidad. De esta manera, Domain Driven Design permite una mayor flexibilidad que si entrelazara la lógica de su negocio, el acceso a la base de datos, el acceso al servicio y el código de la interfaz de usuario todos juntos, pero a costa del tiempo de producción. El diseño dirigido por dominio sirve a las aplicaciones de nivel empresarial mejor que las aplicaciones pequeñas porque las aplicaciones de nivel empresarial tienden a tener un mayor costo durante el tiempo de desarrollo inicial en relación con el valor comercial y, debido a que son más complejas, también están más sujetas a cambios que requieren una mayor flexibilidad a nivel mundial. costo reducido en el tiempo.
En DDD, ¿el modelo de persistencia y el modelo de dominio son cosas diferentes?
En DDD tienes el modelo de dominio y el repositorio. Eso es todo. Si dentro del repositorio persistirá su modelo de dominio directamente O lo convertirá a un modelo de persistencia antes de persistir, ¡depende de usted! Es una cuestión de diseño, tu diseño. Es un detalle de implementación de su repositorio y no importa para el dominio en sí.
Como han señalado otras respuestas, cada opción tiene sus pros y sus contras. Mira esto respuesta donde detallo algunos de ellos.
En DDD, ¿el modelo de persistencia y el modelo de dominio son cosas diferentes?
Sí, pero eso no implica necesariamente un conjunto diferente de clases para representar explícitamente el modelo de persistencia.
Si utiliza una base de datos relacional para la persistencia, un ORM como NHibernate puede encargarse de representar el modelo de persistencia a través de asignaciones a clases de dominio. En este caso, no hay clases de modelo de persistencia explícitas. El éxito de este enfoque depende de las capacidades de mapeo del ORM. NHibernate, por ejemplo, puede admitir una clase de mapeo intermedio a través de mapeos de componentes. Esto permite el uso de una clase de modelo de persistencia explícita cuando surge la necesidad.
Si usa una base de datos de documentos para la persistencia, generalmente hay menos necesidad de un modelo de persistencia, ya que el modelo de dominio solo necesita ser serializable para ser persistente.
Por lo tanto, utilice una clase de modelo de persistencia explícita cuando exista una asignación compleja que no se pueda lograr con las asignaciones de ORM al modelo de dominio. La diferencia entre el modelo de dominio y el modelo de persistencia permanece independientemente de la implementación.