DDD - Modelo de Persistencia y Modelo de Dominio

Solo piénselo de esta manera, el modelo de dominio no debe depender de nada y no debe tener ningún código de infraestructura dentro de él. El modelo de dominio no debe ser serializable o heredar de algunos objetos OR o incluso compartirlos. Todos estos son problemas de infraestructura y deben definirse por separado del modelo de dominio.

Pero, eso es si está buscando ir por DDD puro y su proyecto valora la escalabilidad y el rendimiento sobre la velocidad de desarrollo inicial. Muchas veces, mezclando las preocupaciones de infraestructura con su "modelo de dominio" pueden ayudarlo a lograr grandes avances en velocidad a costa de la escalabilidad. El punto es, usted necesita preguntarse, " Son los beneficios de DDD puro vale la pena el costo en la velocidad de desarrollo?". Si su respuesta es sí, entonces aquí está la respuesta a su pregunta.

Comencemos con un ejemplo en el que su aplicación comienza con un modelo de dominio y resulta que las tablas de la base de datos coinciden exactamente con su modelo de dominio. Ahora, tu la 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 puede necesitar des-normalizar su base de datos solo para mantenerse al día. Por lo tanto, 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 de la forma en que eran antes y ahora trozos de sus entidades de dominio se distribuyen en varias tablas en lugar de 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 desglosar 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 el nuevo modelo de persistencia y el modelo de dominio.

Mantener estos diseños separados tiene varias ventajas, como la escalabilidad, el rendimiento y el tiempo de reacción a los cambios de bd de emergencia, pero debe sopesarlos 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 aplicaciones empresariales a gran escala.

ACTUALIZACIÓN PARA LOS COMENTARISTAS

En el mundo del desarrollo de software, hay N-ésimo número de posibles solución. Debido a esto, existe una relación inversa indirecta entre la flexibilidad y la velocidad inicial de desarrollo. Como un ejemplo simple, podría codificar la lógica en una clase o podría escribir una clase que permita que las reglas de lógica dinámica se pasen a ella. La primera opción tendría una mayor velocidad de desarrollo, pero al precio de un menor grado de flexibilidad. Esta ú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-ésimo número de soluciones posibles.

Hay muchas herramientas disponibles que le ayudan a aumentar su velocidad y flexibilidad de desarrollo inicial. Por ejemplo, una herramienta OR puede aumentar la velocidad de desarrollo para su código de acceso a la base de datos, al tiempo que le brinda la flexibilidad de elegir las implementaciones de base de datos específicas que admite OR. Desde su perspectiva, esto 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 en función del costo del tiempo de desarrollo en relación con el valor de la necesidad del negocio.

Pero, para esta conversación en estilos de codificación, que es esencialmente lo que es el Diseño impulsado por el Dominio, tienes que tener en cuenta el tiempo que tomó escribir esa herramienta que estás usando. Si fuera a escribir esa herramienta OR o incluso escribir su lógica de acceso a la base de datos de tal manera que soporte todas las implementaciones que da la herramienta usted, tomaría mucho más tiempo que si usted fuera a sólo hard-codificar la implementación específica que planea utilizar.

En resumen, las herramientas pueden ayudarlo a compensar su propio tiempo para la producción y el precio de la flexibilidad, a menudo distribuyendo el costo de ese tiempo a todos los que compran la herramienta. Sin embargo, cualquier código, incluido el código que utiliza una herramienta, permanecerá afectado por la relación velocidad/flexibilidad. De esta manera, el Diseño impulsado por el dominio permite una mayor flexibilidad que si estuviera enrede la lógica de su negocio, el acceso a la base de datos, el acceso al servicio y el código de interfaz de usuario, todo junto, pero a costa del tiempo de producción. El diseño impulsado por el 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 para el tiempo de desarrollo inicial en relación con el valor comercial y porque son más complejas, también están más sujetas a cambios que requieren una mayor flexibilidad a un costo reducido en el tiempo.