oop - sistema - modelo de dominio herencia
DDD-Modelo de Persistencia y Modelo de Dominio (3)
Estoy tratando de aprender el diseño impulsado por dominio (DDD), y creo que tengo la idea básica. Pero hay algo que me confunde.
En DDD, ¿el modelo de persistencia y el modelo de dominio son diferentes? Quiero decir, diseñamos nuestro dominio y nuestras clases pensando solo en el dominio; esta bien. Pero después de eso, cuando estamos construyendo nuestros repositorios o cualquier otro sistema de persistencia de datos, ¿deberíamos crear otra representación de nuestro modelo para usar en la capa de persistencia?
Estaba pensando que nuestro modelo de dominio también se utiliza en persistencia, lo que significa que nuestros repositorios devuelven nuestros objetos de dominio de las consultas. Pero hoy, leí esta publicación, y estoy un poco confundido:
¡Sólo detenerlo! El modelo de dominio no es el modelo de persistencia
Si eso es cierto, ¿cuál sería la ventaja de tener objetos de persistencia separados de objetos de dominio?
En DDD, ¿el modelo de persistencia y el modelo de dominio son diferentes?
En DDD tiene el modelo de dominio y el repositorio . Eso es. Si está dentro del repositorio, persistirá directamente en su modelo de dominio o lo convertirá en un modelo de persistencia antes de persistir, depende de usted. Es una cuestión de diseño, tu diseño.
Como han señalado otras torres, cada opción tiene sus ventajas y desventajas. Echa un vistazo a esta answer donde detallo algunos de ellos.
En DDD, ¿el modelo de persistencia y el modelo de dominio son diferentes?
Sí, pero eso no implica necesariamente un conjunto diferente de clases para representar explícitamente el modelo de persistencia.
Si se usa una base de datos relacional para persistencia, un ORM como NHibernate puede encargarse de representar el modelo de persistencia mediante 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 soportar 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 se usa una base de datos de documentos para la persistencia, generalmente hay incluso menos necesidad de un modelo de persistencia ya que el modelo de dominio solo necesita ser serializable para poder ser conservado.
Por lo tanto, use una clase de modelo de persistencia explícita cuando exista una asignación compleja que no se pueda lograr con las correlaciones de ORM con el modelo de dominio. La diferencia entre el modelo de dominio y el modelo de persistencia permanece independientemente de la implementación.
Solo piénselo de esta manera, el modelo de dominio no debe depender de nada y no debe tener un código de infraestructura. El modelo de dominio no debe ser serializable o heredar de algunos objetos ORM o incluso compartirlos. Estas son todas preocupaciones de infraestructura y deben definirse por separado del modelo de dominio.
Pero eso es si está buscando ir a DDD puro y su proyecto valora la escalabilidad y el rendimiento a 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 debes preguntarte: "¿Los beneficios de la DDD pura valen la pena en la velocidad del desarrollo?". Si su respuesta es sí, esta es la respuesta a su pregunta.
Comencemos con un ejemplo donde su aplicación comienza con un modelo de dominio y sucede 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 obtiene un nuevo diseño de base de datos que manejará sus necesidades de rendimiento, pero ahora las tablas son muy diferentes de como eran antes y ahora los trozos de sus entidades de dominio están distribuidos en varias tablas en lugar de de lo que es 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 coincida 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 para mantener estos diseños separados, como la escalabilidad, el rendimiento y el tiempo de reacción a los cambios de DB de emergencia, pero debe compararlos con el costo y la velocidad del desarrollo inicial. En general, los proyectos que obtendrán el mayor beneficio de este nivel de separación son las aplicaciones empresariales a gran escala.
ACTUALIZACIÓN PARA COMENTARIOS
En el mundo del desarrollo de software, hay un número N 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 la lógica en una clase o podría escribir una clase que permita que se pasen reglas lógicas dinámicas. La primera opción tendría una mayor velocidad de desarrollo, pero a costa 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 dentro de cada lenguaje de codificación porque siempre hay un número N de posibles soluciones.
Hay muchas herramientas disponibles que lo ayudan a aumentar su velocidad de desarrollo inicial y su flexibilidad. 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 soporte ORM. Desde su punto de vista, esta es una ganancia neta en tiempo y flexibilidad menos el costo de la herramienta (algunos de los cuales son gratuitos) que puede o no valer la pena en función del 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 el dominio, debe tener en cuenta el tiempo que llevó escribir esa herramienta que está utilizando. Si tuviera que escribir esa herramienta ORM o incluso escribir su lógica de acceso a la base de datos de tal manera que sea compatible con todas las implementaciones que la herramienta le brinda, tomaría mucho más tiempo que si solo codificara la implementación específica que planea en usar
En resumen, las herramientas pueden ayudarlo a compensar su propio tiempo con la producción y el precio de la flexibilidad, a menudo distribuyendo el costo de ese tiempo a todos los que adquieren la herramienta. Sin embargo, cualquier código que incluya el código que utiliza una herramienta, se verá afectado por la relación velocidad / flexibilidad. De esta forma, Domain Driven Design permite una mayor flexibilidad que si estuviera enredado con su lógica de negocio, acceso a bases de datos, acceso a servicios y código UI, todo junto, pero a costa de tiempo para la producción. Domain Driven Design sirve mejor a las aplicaciones de nivel empresarial que a las pequeñas porque las de nivel empresarial tienden a tener un mayor costo para el tiempo de desarrollo inicial en relación con el valor de negocio y porque son más complejas, también están más sujetas a cambios que requieren una mayor flexibilidad a costo reducido a tiempo.