¿Los objetos inmutables y DDD van juntos?

Considere un sistema que use DDD (también: cualquier sistema que use un ORM). El objetivo de cualquier sistema de manera realista, en casi todos los casos de uso, será manipular esos objetos de dominio. De lo contrario, no hay un efecto o propósito real.

La modificación de un objeto inmutable hará que genere un nuevo registro después de que el objeto persista, lo que crea una hinchazón masiva en el origen de datos (a menos que elimine registros anteriores después de las modificaciones).

Puedo ver el beneficio de usar objetos inmutables, pero en este sentido, nunca puedo ver un caso útil para usar objetos inmutables. ¿Esto esta mal?

¡La computación utilizando objetos inmutables (como en la programación funcional) no implica necesariamente persistir en cada objeto que se genera!

¿Inmutable en el dominio significa que tiene que ser inmutable en la base de datos? Por ejemplo, considere lo siguiente suponiendo que el cliente siempre tenga una dirección:

customer.address = new Address('My Castle', 'Kings street');
customer_repo.save(customer);

ahora se ejecuta el siguiente sql teniendo en cuenta que la identificación del cliente es 1:

INSERT INTO addresses (customer_id, name, street)
VALUES (1, 'My Castle', 'Kings street');

ahora se realiza el siguiente cambio en la dirección:

customer.address = new Address('Pauper palace', 'Outlands');
customer_repo.save(customer);

y la capa de persistencia, siendo muy inteligente, ejecuta el siguiente sql:

UPDATE addresses SET name='Pauper palance', street='Outlands'
WHERE customer_id = 1;

De esta manera, evita la sobrecarga de una instrucción DELETE AND INSERT separada. También creo que algunos RDBMS tienen INSERT REPLACE o algo así. MySql ha REEMPLAZADO .

En DDD, los objetos inmutables se equiparan con los objetos de valor. Estos objetos no son entidades, no tienen identidad. Por lo tanto, siempre persisto los objetos de valor como columnas de la entidad en la que están contenidos (con N / Hibernate puede usar Componentes para eso). No tienen mesa propia.

Depende de cómo se asigna el objeto inmutable en la base de datos. Si es solo un componente como DateTime (de la biblioteca Joda Time), cambiar el valor dará como resultado una actualización en lugar de una inserción. Sin embargo, si lo inmutable es más complejo y requiere una fila en una tabla, entonces tiene el problema de hinchazón.

Supongo que, aunque es un argumento débil, podría implementar una pista de auditoría de esta manera. Cada cambio en lo inmutable puede rastrearse a través de los insertos. Sin embargo, hay muchas mejores maneras de hacer esto.

En general, tener objetos de dominio inmutables (en lugar de simplemente sus componentes) parece un poco incompatible con la persistencia.

Eso depende del dominio. DDD no especifica que el paradigma de programación esté orientado a objetos. Sin embargo, el paradigma orientado a objetos es muy adecuado para la aplicación típica que debe persistir en una base de datos.

DDD simplemente declara que debe construir su software en torno a un modelo de dominio que represente el problema real que el software está tratando de resolver. Si ese problema fuera, por ejemplo, matemático por naturaleza, entonces la implementación de la capa de dominio utilizando programación funcional y estructuras de datos inmutables tendría mucho sentido.

Si, por otro lado, el problema es más bien una aplicación empresarial típica, y está utilizando estructuras de objetos inmutables para todos sus objetos de dominio, entonces diría que no está siguiendo DDD. Puedo proponer al menos dos argumentos:

• Su implementación no representa un modelo de dominio de su dominio problemático. Su dominio problemático en este caso consiste en entidades que tienen un estado para modificar. Y no es así como lo ha implementado.

• No tienes un lenguaje omnipresente. El lenguaje y los conceptos en el modelo de dominio no siguen lo que usan los expertos en dominio.

Nota: DDD utiliza objetos inmutables cuando corresponde, solo se denominan objetos de valor.

Por lo tanto, no digo que no pueda crear una aplicación de base de datos utilizando estructuras de datos puramente funcionales, y no digo que no deba hacerlo. Simplemente no creo que pueda llamarlo DDD, dependiendo del tipo de aplicación

Si está utilizando un ORM como Hibernate / NHibernate, puede configurar su opción en cascada para eliminar automáticamente los objetos huérfanos. Si una persona tiene una dirección de objeto de valor, cuando cambie la dirección, se guardará la nueva y se eliminará la anterior porque ahora está huérfana.

Los objetos de valor son casi siempre inmutables en DDD y el patrón de peso mosca se puede usar para mantener la duplicación de ese objeto de valor en la memoria, al igual que .NET con cadenas. El principal inconveniente es la memoria de un lado y el otro lado es la eficiencia de la creación. Con el patrón de peso mosca, se debe hacer una comparación basada en valores para determinar si algún objeto de valor nuevo o reconstituido ya está dentro de la memoria caché de peso mosca, pero cualquier otra comparación después de ese punto generalmente se puede hacer de forma segura por referencia ya que se aplica una sola instancia. De cualquier manera, ya sea que se use o no peso mosca, los objetos de valor aún se vuelven inmutables porque solo tienen una identidad intrínseca y, por lo tanto, cambiar su valor cambiaría su identidad.

Hay otra forma de usar objetos inmutables ...

En lugar de almacenar los valores 5.0, 6.0, 7.0, 8.0 y copiar todo el registro cada vez, puede almacenar algo como esto: 5.0, +1.0, +1.0, +1.0, y luego construir una dependencia correctamente para reconstruir la secuencia 5.0 , 6.0, 7.0, 8.0. De esta manera, las pequeñas modificaciones solo requieren una pequeña cantidad de memoria ...