Un agregado es un objeto de dominio, que a su vez depende de otro objeto de dominio raíz. Este primero tiene su propio significado, pero a su vez depende de otro. Fácilmente estos podrían ser confundidos con una colección, sin embargo, una colección es simplemente un listado de valores, mientras que los agregados son concebidos como unidades conceptuales dentro del sistema.
De la misma forma que un objeto de dominio no es un reflejo de la base de datos, los agregados tampoco lo son. Pueden reflejar información almacenada en la misma, pero no son una equivalencia, no se trata de meras estructuras de datos o primitivos.
El uso de esta estrategia para definir nuestros modelos limitará el número de interacciones que tendrás nuestros modelos. De esta forma, nuestro elemento raíz no tendrá que saber como manejar la información de sus agregados, sino que será el propio agregado quien permita llamar ciertos métodos que representen acciones dentro de nuestro dominio desde el elemento raíz.
De esta forma aplicamos la Ley de Deméter, consiguiendo que nuestro modelo raíz no conozca demasiados detalles a cerca de la implementación del agregado y por tanto evitando efectos colaterales en cambios venideros.
Por definición solo los objetos raíz deben de poseer un Repository (No confundir con un DAO). Todas las operaciones para persistir un objeto raíz deberán de realizarse a través de su Repository y será este quien se encargue de manejar sus agregados.
Ahora bien, ¿Qué ocurre cuando un raíz se relaciona con otro raíz? En este caso no estamos hablando de un agregado per se, sino que estaremos hablando de dos, cada uno de ellos con su propio Repository.
Aquí es donde entra en juego el concepto de Domain Service. Este servicio recibirá mediante injección de dependencias el Repository correspondiente a cada objeto de dominio.
El objeto de dominio que encapsula al otro no deberá tener un agregado, sino un listado de identificadores.
Cuando el Domain Service reciba el objeto de dominio, podrá hacer uso de los Repositories inyectados para recuperar el segundo objeto raíz, realizar las operaciones pertinentes con él y finalmente almacenarlo.
Todo esto constituye el denominado patrón agregado, a través del cual podemos crear agregados de objetos de dominio, que pueden ser añadidos a un objeto raíz, reduciendo el nivel de acoplamiento y delegando responsabilidad.
Para persistirlo debemos tener en cuenta si se trata de otro objeto raíz o simplemente de otro objeto del dominio.
En caso de tratarse de dos objetos raíz deberemos desechar la idea de agregado un listado de identificadores en el objeto de tal forma que utilizando un Domain Service, este pueda realizar las acciones de persistencia.
Por el contrario si se trata de un objeto de dominio, deberá ser persistido a través del Repository correspondiente del objeto raíz.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
