Los agregados no son elementos persistibles.

Si habéis leído ciertas entradas en este blog; alguna vez me habréis visto comentar que hacer que un agregado sea un elemento que se guarda en persistencia a bloque (y por ende se lee de persistencia a bloque) es un detalle de implementación que no es obligatorio y no debe afectar al diseño del agregado ni que este dependa del esquema de persistencia.

Pues bien: Ni pu** caso, ni detalle de implementación ni pitufos en vinagre. Directamente NO. No es un elemento persistible. Un agregado no es un puñado de "tablas de BD" representadas en memoria, y un agregado raíz no es añadir funciones públicas a una de esas "tablas". De hecho, un agregado raíz no tiene ni porqué tener identificador único.

Un agregado es un elemento que se encarga de comprobar las invariantes del dominio y aplicar las reglas de los cambios de ese mismo dominio.

Comprobar las invariantes del dominio significa: "¿Puedo hacer esta operación según el estado actual del sistema?" y para ello leemos de persistencia la información justa y necesaria para ello. Cogemos un campo de una tabla, dos campos de otra tabla, el número de entradas de una tercera, etc; con ello montamos el agregado y este se encarga comprobar que la operación es posible.

Aplicar las reglas de los cambios del dominio significa: "Ahora que ya sé que la operación es posible voy a realizar los cálculos necesarios para obtener el nuevo estado del sistema una vez realizada la operación". A veces es necesaria alguna información del sistema para realizar estos cálculos por lo que la información justa y necesaria para montar el agregado (lo expuesto en el punto anterior) se amplía para que abarque también estos datos.

Ojo, que no estoy diciendo que para montar el agregado no se usen VO's y entidades. Claro que se usan. Esos datos dispersos de persistencia que se necesita leer se usan para crear VO's y entidades para alimentar el agregado y que trabaje con ellos.

Con elemento persistible me refiero a algo como esto:

public class ApplicationServices.MyService{

  public void DoSomething(...){

     MyAggregate agg = myAggRepository.Get(aggId);

     agg.DoSomething(...); //cambia su estado interno con el nuevo estado del sistema

     myAggRepository.Save(agg); //coge su estado interno y lo persiste

  }

}

Al hacer esto te estás cargando todo el DDD y estás volviendo a hacer un sistema CRUD. Como el repositorio no sabe que carajo ha cambiado el agregado (se ha perdido la pretensión de la operación);  lo único que puede hacer es obtener todo el estado interno del agregado y plantarlo en persistencia; incluida información que sólo se ha usado para comprobar las invariantes o realizar cálculos pero que no han cambiado después de la operación. Esto es igual al típico sistema CRUD donde la vista editable se pasa a piñón a persistencia porque no sabemos que quería hacer el usuario más allá de cambiar valores a campos que le presentamos en la vista.

Otra consecuencia perniciosa es que el agregado tiene que exponer en getter(s) su estado interno para que sea recuperado por el repositorio; el repositorio necesita ciertos conocimiento sobre como está implementado el agregado y el agregado los filtra. Nos hemos cargado de un plumazo la abstracción de la implementación, el bajo acoplamiento, la alta cohesión, el Tell Don't Ask y yo qué sé cuántas cosas más.

Dejo para la siguiente entrada la respuesta a la pregunta ¿Y entonces que coj**** hago? con una pista:

“I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.” ~ Alan Kay