Duda sobre Aggregate

[Mariano Castellano]

Hola a todos!

Estoy incursionando en el diseño guiado por el dominio y me surgieron un par de dudas acerca de los Agregados. Les propongo esta situación como ejemplo para poder entender/seguir la filosofía :-).

Supongamos que el ejemplo se trata de un juego, y como todo juego tiene un usuario. Este usuario (User) contiene las características básicas de un usuario normal, común y corriente: Id, Nombre (name), Apellido (surname), Fecha de nacimiento (dateOfBirth) y Dirección (address). Entiendo que el User será una Entity y que el Address será un Value Object, verdad?. Y para poder actualizar la dirección de un usuario tendría que actualizar todo el usuario con una nueva dirección, ya que el Value Object es inmutable. Además de Entity, el User estaría siendo la raíz de un Agregado en mi aplicación, verdad?.

Como en todo juego, o en su mayoría =), hay vidas y acá es cuando entra el problema. Las vidas estarían modeladas fuera del usuario (según como yo lo veo), ya que de lo contrario empezaría a mezclar cosas (Vidas con Dirección de usuario, por ejemplo).

Entonces me quedaría modelado una especie de VidasDeUsuario (UserLives) que contendría las vidas y como referencia el id del usuario. Y acá es donde no me queda claro el concepto de Agregado. Cual sería el agregado en esa situación?, ya que tengo el User y UserLives vinculados por un id nomás. Que pistas me podrían dar para pensar este problema con el enfoque DDD?

Espero que me haya explicado, y gracias de antemano!

Saludos a todos desde Argentina!

[Carlos Peix]

2015-05-26 21:22 GMT-03:00 Mariano Castellano <castellan...@gmail.com>:

Supongamos que el ejemplo se trata de un juego, y como todo juego tiene un usuario.

Quizás podríamos cuestionar esta primera elección de nombres diciendo que todo juego tiene jugadores. Avanzo más sobre este tema mas abajo.

 

Este usuario (User) contiene las características básicas de un usuario normal, común y corriente: Id, Nombre (name), Apellido (surname), Fecha de nacimiento (dateOfBirth) y Dirección (address). Entiendo que el User será una Entity y que el Address será un Value Object, verdad?. Y para poder actualizar la dirección de un usuario tendría que actualizar todo el usuario con una nueva dirección, ya que el Value Object es inmutable. Además de Entity, el User estaría siendo la raíz de un Agregado en mi aplicación, verdad?.

Si, pero no lo llamaría Usuario. Quizás Persona sea una mejor opción para representar el concepto de una persona física (nombre, apellido, dirección, fecha de nacimiento), pensá en los datos que aparecen en un documento o cédula de identificación.

Que esa persona sea un usuario de una aplicación o jugador en un juego, es un concepto de otro contexto (bounded context).

 

Como en todo juego, o en su mayoría =), hay vidas y acá es cuando entra el problema. Las vidas estarían modeladas fuera del usuario (según como yo lo veo), ya que de lo contrario empezaría a mezclar cosas (Vidas con Dirección de usuario, por ejemplo).

Aquí es donde el concepto de Jugador cobra mas sentido. Habría que pensar con mas detenimiento si llamamos jugador a la persona que suele jugar el juego (donde estaría, por ejemplo, el ranking de los puntajes obtenidos en distintas instancias del juego) y llamamos Sesión (o algo parecido) a la participación de un Jugador en la instancia del juego y es ahí donde estarían las vidas que mencionás, siendo la raíz de ese agregate, la Sesion.

 

Entonces me quedaría modelado una especie de VidasDeUsuario (UserLives) que contendría las vidas y como referencia el id del usuario. Y acá es donde no me queda claro el concepto de Agregado. Cual sería el agregado en esa situación?, ya que tengo el User y UserLives vinculados por un id nomás. Que pistas me podrían dar para pensar este problema con el enfoque DDD?

Estos (User y UserLives), o los que propuse en mi razonamiento (Persona, Jugador, Sesion), son agregados distintos que tienen referencias (Sesion -> Jugador -> Persona).

Una de las eurísticas que utilizo para razonar donde termina un agregado es el ciclo de vida (cuando lo creás, cuando o borrás, etc). Por ejemplo, cada vez que creas un Jugador, creas una Sesión? creo que no, al revés menos aun. Entonces hay grandes posibilidades de que sean agregados diferentes.

Cuando borras una sesión, deberías borrar al jugador? probablemente no.

 

Espero que me haya explicado, y gracias de antemano!

Lo mismo digo!

 

Saludos a todos desde Argentina!

Lo mismo digo! 

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+un...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a ddd...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/ddd-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Mariano Castellano]

Muchas gracias por tu respuesta!.

Entiendo lo que me decís pero aún tengo dudas en ciertos momentos, por ejemplo:

Supongamos que también tengo la posibilidad de actualizar datos de la Persona, por ejemplo, en su perfil del juego. Por su puesto que no usaría el agregado Sesión para llegar a la Persona y actualizar sus datos. Pero esta Persona seria otro agregado en este caso, verdad?. Y ahí la pregunta: la Persona puede ser un agregado y a la vez ser parte de otro agregado (el de sesion)?.

Gracias y saludos!

Mariano.

[Carlos Peix]

Como decía en mi correo anterior, yo no colocaría el prefil de juego en el agregado Persona sino en el agregado Jugador. Para entender esto probablemente te convenga leer sobre Roles en el modelado de objetos.

De todos modos, tu pregunta sigue siendo válida.

Creo que el agregado Jugador está separado del agregado de Persona, la clase Jugador tiene una referencia a Persona pero Persona es otro agregado.

De hecho, es muy probable que los datos de la persona (nombre, fecha de nacimiento) se actualicen en contextos muy diferentes a las actualizaciones, por ejemplo, del perfil del juego.

Gracias y saludos!

Mariano.

[Mariano Castellano]

El 27 de mayo de 2015, 9:37, Carlos Peix <carlo...@gmail.com> escribió:

2015-05-27 8:27 GMT-03:00 Mariano Castellano <castellan...@gmail.com>:

Muchas gracias por tu respuesta!.

Entiendo lo que me decís pero aún tengo dudas en ciertos momentos, por ejemplo:

Supongamos que también tengo la posibilidad de actualizar datos de la Persona, por ejemplo, en su perfil del juego. Por su puesto que no usaría el agregado Sesión para llegar a la Persona y actualizar sus datos. Pero esta Persona seria otro agregado en este caso, verdad?. Y ahí la pregunta: la Persona puede ser un agregado y a la vez ser parte de otro agregado (el de sesion)?.

Como decía en mi correo anterior, yo no colocaría el prefil de juego en el agregado Persona sino en el agregado Jugador. Para entender esto probablemente te convenga leer sobre Roles en el modelado de objetos.

Totalmente de acuerdo, si puse lo contrario mil disculpas, lo venia escribiendo en el colectivo jaja. El perfil del jugador como bien decís lo colocaría en el Jugador y no en la Persona.

 

De todos modos, tu pregunta sigue siendo válida.

Creo que el agregado Jugador está separado del agregado de Persona, la clase Jugador tiene una referencia a Persona pero Persona es otro agregado. 

De hecho, es muy probable que los datos de la persona (nombre, fecha de nacimiento) se actualicen en contextos muy diferentes a las actualizaciones, por ejemplo, del perfil del juego.

Claro, Jugador y Persona son agregados en contextos muy distintos. Depende en que contexto esté hablando va a ser una Entity o un Aggregate, verdad?.

Muchas gracias por la respuesta!.

Gracias y saludos!

Mariano.

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+un...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a ddd...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/ddd-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "DDD-es" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/ddd-es/cAaSp8fQXDE/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a ddd-es+un...@googlegroups.com.

[Carlos Peix]

2015-05-27 10:12 GMT-03:00 Mariano Castellano <castellan...@gmail.com>:

De hecho, es muy probable que los datos de la persona (nombre, fecha de nacimiento) se actualicen en contextos muy diferentes a las actualizaciones, por ejemplo, del perfil del juego.

Claro, Jugador y Persona son agregados en contextos muy distintos. Depende en que contexto esté hablando va a ser una Entity o un Aggregate, verdad?.

En mi opinión, el concepto de Entity y Aggregate se relacionan de otra manera.

Creo que puede haber Aggregates de una sola entidad (el Aggregate Root) y otros que tengan mas objetos ademas del Aggregate root.

[Mariano Castellano]

Aahh entiendo!. 

Voy a leer un poco mas antes de seguir con las preguntas :-)

Muchas gracias por las respuestas y nos vemos por alguna calle de Buenos Aires!

--

[Luis Alberto Baigorria Rodas]

Interesante Analisis! Saludos desde Santa Cruz Bolivia. Me ha ayudado a comprender mejor el concepto de Agregados en DDD.

--

Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+un...@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a ddd...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/ddd-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Luis Alberto Baigorria Rodas
Cel. (591) 731-12829 - Blog· www.uialberto.wordpress.com 

Engineer, software developer, thinker and blogger interested in technology, design and Web development. 

"Acquire Wisdom and Live with Passion."

Skype: uialberto

 No me imprimas si no es necesario. Protejamos el medio ambiente

Antes de imprimir este mensaje, considere si es necesario hacerlo. El medio ambiente está en nuestras manos. Before printing this message, consider if it is necessary to do it. The environment is in our hands.

[Mariano Castellano]

Una consulta más que de las que me quedó en el tintero..

Supongamos que persisto el agregado Sesión (con su jugador y dichos Jugador con su Persona), no habría información de la Persona duplicada? Ya que yo puedo actualizar, en otro contexto, los datos de la Persona?.
Pregunto esto porque me imagino que la Persona no sólo existiría en la Sesión sino que también como agregado independiente.

Espero que hayan entendido mi inquietud.

Muchas gracias y saludos!!

[Carlos Peix]

Hola Mariano,

No habria información repetida porque la relación entre Sesion y Jugador, lo mismo que entre Jugador y Persona (pongamos que los tres sean diferentes aggregates, seria de referencia.

Esto implica que, cuando se persiste, por ejemplo, un Jugador, no se persiste Persona. Obviamente esto se logra mediante configuración del ORM, por ejemplo.

Un ejemplo que, espero, sea mas claro: En el dominio de ventas, por ejemplo, tenemos una Venta, con su coleccion de ItemsDeVenta que generan el aggregate Venta. Luego, cada item de venta, incluye un Producto pero como referencia (otro aggregate). La venta, además, referencia a un Cliente (otro aggregate).

Cuando se persiste la venta, no se guardan copias separadas de cada producto o cada cliente.

Un saludo

----------------------------------
Carlos Peix

--

[Mariano Castellano]

Entiendo perfectamente, a eso quería llegar. 

En la persistencia solo se guarda la referencia, en un ORM tal vez sea mas claro el ejemplo, pero en una base de datos NoSQL tal vez se complique, pero eso ya escapa a este hilo.

Muchas gracias!

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "DDD-es" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/ddd-es/cAaSp8fQXDE/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a ddd-es+un...@googlegroups.com.

[Carlos Peix]

Me gustaría organizar una reunión virtual, como un Webinar de 30 o 40 minutos en el que presentemos algún caso (por ejemplo este, si nos permite Mariano!), mas o menos a las 20hs de España, 15hs de Argentina, donde podamos discutir un poco estos temas.

Podría ser la próxima semana o la que sigue.

Les suena?

----------------------------------
Carlos Peix

[Mariano Castellano]

Yo me sumo!. Por su puesto que si, podemos tratar este ejemplo.

Lo que me complica es el horario, a esa hora me encuentro trabajando. Por mi parte, tengo disponible después de las 21:00 hs de Argentina. 

Tal vez podríamos ver quienes se suman y a partir de ahí ver un horario acorde a quienes participan.

Saludos a todos!

[Carlos Peix]

Propuse esa hora puesto que estamos en DDD-Es(paña) :-)

----------------------------------
Carlos Peix

[Mariano Castellano]

Já!, pensé que era es(pañol) jajaja. Trato de acoplarme a pleno!

[nelopa...@gmail.com]

Me sumo a la reunión.

[Mariano Castellano]

Buenas a todos!

Sigo con preguntas sobre Aggregates =). Supongamos que tengo un Aggregate que representa el Gameplay de un juego y éste contiene la referencia a dos Players, siendo Player otro Aggregate.

En un momento de la partida, el juego llega a su fin y necesito darle monedas al ganador. Pero esto no lo puedo hacer porque: el responsable de otorgar monedas no es el juego y además no tengo el Player, tengo solo la referencia (ID).

Lo que pensé fue lo siguiente: 

1- pedir el estado del juego en mi Servicio de Aplicación y si esta finalizado obtener el ID del Player ganador y otorgarle las monedas. Pero no me convence., porqué tendría que evaluar eso fuera del GamePlay?.

2-Lo intenté pensar por el lado de Eventos de dominio pero estoy en la misma, solo tengo los IDs, tendría que ir a buscarlos indefectiblemente.

Espero que se haya entendido mi duda, saludos y muchas gracias!

Mariano.

[Alfredo Casado]

Para este caso la solución con eventos me parece más acertada, cuando se termine un GamePlay pueden ocurrir muchas cosas que parecen independientes/laterales al propio gameplay, por ejemplo tu caso de sumarle monedas al jugador, apuntar la partida en un historico, actualizar las listas de mejores jugadores si la puntuación lo merece, notificar a los colegas del ganador por twitter etc,etc.

El GamePlay cuando se den las condiciones de victoria podría lanzar un evento tal que:

GameFinished

   - gameId

   - winnerId

   - looserId..

Los eventos normalmente son estructuras de datos de simples (no contienen entidades o agregados), estos eventos incluso podrían ser capturados y procesados por BoundedContexts diferentes. Luego cuando captures el evento por ejemplo en un AS, pongamos el WalletService (servicio de monedero) este servicio tendrá que recuperar el objeto player de la persistencia y añadirle las monedas, aunque esto lo puedes enfocar de otra manera, y tener un objeto por ejemplo PlayerWallet que no tiene toda la información del usuario sino sólo aquello relevante desde el punto de vista del monedero del usuario y que contendrá sólo los métodos relevantes al monedero (por ejemplo, ¿donde vas a meter la lógica que dice cuantas monedas se añaden al usuario?, este objeto PlayerWallet puede ser un buen sitio para hacerlo, quizá el Player si le vas metiendo muchas cosas de este estilo termine siendo un objeto muy gordo, recuerda el single responsability principle).

Esto es sólo un enfoque de los muchos posibles claro, espero haberte dado alguna idea que te ayude.

[Carlos Peix]

Hola Mariano,

Tengo algunos comentarios sobre tu descripción, mas allá de donde decidas ubicar la lógica (eventos, servicios, etc. Mas sobre eso al final).

2015-06-08 16:32 GMT-03:00 Mariano Castellano <castellan...@gmail.com>:

Sigo con preguntas sobre Aggregates =). Supongamos que tengo un Aggregate que representa el Gameplay de un juego y éste contiene la referencia a dos Players, siendo Player otro Aggregate.

Reconozco que tuve que ir a wikipedia para entender que es GamePlay :-)

 

En un momento de la partida, el juego llega a su fin y necesito darle monedas al ganador. Pero esto no lo puedo hacer porque: el responsable de otorgar monedas no es el juego y además no tengo el Player, tengo solo la referencia (ID).

Decías mas arriba que en el GamePlay tenías una referencia a cada Player pero ahora decis que tenés el ID.

Asumiendo que estás hablando de objetos de dominio, en mi opinión un ID no es la referencia, es un dato que te permite, Repository mediante, acceder a una referencia. Una referencia es una variable de tipo Player que contiene una instancia de Player, el mismo concepto de referencia de C#.

Entonces, dentro del dominio, acceder al Player debiera ser trivial.

 

Lo que pensé fue lo siguiente: 

1- pedir el estado del juego en mi Servicio de Aplicación y si esta finalizado obtener el ID del Player ganador y otorgarle las monedas. Pero no me convence., porqué tendría que evaluar eso fuera del GamePlay?.

2-Lo intenté pensar por el lado de Eventos de dominio pero estoy en la misma, solo tengo los IDs, tendría que ir a buscarlos indefectiblemente.

Si estamos hablando del dominio, no me parece bien que accedas a un servicio de aplicación. Es una referencia en el orden inverso al natural. Esta es una necesidad que surge solo porque no tienes una referencia viva al objeto.

Por el lado de los eventos de dominio, no veo porqué tienes solo IDs, debieras tener objetos con referencias vivas.

Me parece bien la sugerencia de Alfredo pero lo que yo levantaría en ese evento son objetos de dominio, no IDs.

En cualquier caso, debemos ser cuidadosos sobre lo que hacemos con esos IDs y/o objetos. Es muy facil que podamos meternos en problemas, tanto si modificamos un objeto pasado en un evento como si, con el ID, recuperamos y modificamos un objeto que ya tenemos en memoria en la sesión fuera del evento. Cuidado con eso.

[Mariano Castellano]

Alfredo, Carlos, muchas gracias por las respuestas!.

Carlos, claro, decía que tenia una referencia a Player pero en realidad es el ID, me guié por el artículo de Vernon que dice que es recomendable referenciar un Aggregate desde otro Aggregate por identidad, por lo que decís seguramente lo interpreté mal.

Lo que si, cuando persista el Gameplay voy a tener que configurar el ORM o algún serializador (para base de datos nosql) que guarde solo la referencia del Player, verdad? Como lo habíamos hablado hace un par de semanas.

Muchas gracias y saludos!

Mariano.

[Carlos Peix]

2015-06-09 8:55 GMT-03:00 Mariano Castellano <castellan...@gmail.com>:

Alfredo, Carlos, muchas gracias por las respuestas!.

Carlos, claro, decía que tenia una referencia a Player pero en realidad es el ID, me guié por el artículo de Vernon que dice que es recomendable referenciar un Aggregate desde otro Aggregate por identidad, por lo que decís seguramente lo interpreté mal.

No creo que hayas interpretado mal. No quiero opinar sobre esa sugerencia sin leer el articulo completo y ahora no tengo mucho tiempo. 

Lo que si, cuando persista el Gameplay voy a tener que configurar el ORM o algún serializador (para base de datos nosql) que guarde solo la referencia del Player, verdad? Como lo habíamos hablado hace un par de semanas.

En el caso de un ORM (base de datos relacional), eso es justo lo que hace un ORM: cuando persistis guarda el ID en la tabla, Cuando recuperas, toma el ID, carga el objeto desde la otra tabla y te da la instancia en una variable.

Sobre bases de datos NoSql supongo que el serializador debe tener una inteligencia similar.

Muchas gracias y saludos!

Mariano.

--

[Michael-Jorge Gómez Campos]

Hola Mariano, me uno al lio para ver si conseguimos hacerte ver la luz. Antes de nada, una cosa que te recomiendo tras mucha experiencia es que, en ocasiones, no se debe ser tan estricto/radical a la hora de aplicar este tipo de metodologias porque en el fondo tienen que ayudar a que el sistema en global funcione tal y como exige "el cliente". Por ejemplo, para sistemas distribuidos se aplica lo que se conoce como el Teorema del CAP donde, de forma muy simplificada e incompleta, te dicen que tu sistema puede ser consistente (cualquier peticion sobre un dato desde cualquier nodo del sistema debe ofrecer la misma informacion) o disponible (las peticiones hacia cualquier nodo deben ofrecer respuesta tanto de si pueden ejecutar la peticion como si no, y timeout no es una respuesta válida), pero nunca puedes conseguir las dos cosas a la vez, ya que una transaccion larga para conseguir consistencia puede causarte timeouts de otras peticiones al sistema. Podrias usar una cache para paliar el problema, por ejemplo, y tendras disponibilidad pero con una cache no tienes consistencia de datos ya que tu sistema tiene partes desactualizadas. Y lo mejor que puedes hacer es no luchar contra ello porque es perder el tiempo.

En el caso del DDD, puedes aplicar algo parecido: o tener tu modelo completamente modelado en un sistema de agregados y que cuando apliques cambios en el sistema simplemente por cascada las entidades se vayan actualizando y luego salvar los cambios, o uno mas libre, representado mediante contextos en los que cada contexto reprsenta una parte del modelo de forma especializada, aunque ello signifique que varios contextos definan las mismas entidades pero con diferente lógica de negocio, y que se comuniquen entre sí mediante eventos de dominio. Por ejemplo en tu caso, no veo incorrecto que tengas definido un contexto donde el agregado de Juego tenga referenciados solo los id de los jugadores si en ese contexto no necesitas nada mas de ellos. Lanzas un evento de cambio y, en otro contexto, puedes tener el modelo de una entidad Juego mas simple con entidades Jugador más robustas (gestión de estado o puntuación).

Como todo decidir qué escoger viene dadp por las exigencias de la aplicación. Si se requiere un sistema que responda rápido hay que jugar con asincronías, y un modelo orientado a eventos te resultaria más cómodo para conseguir los mejores beneficios. En cambio un sistema donde la consistencia de datos es fundamental, un sistema más compacto puede ofrecerte el mejor beneficio ya que no tendrias que hacer tantos saltos de código que a la larga penalizan en tiempo y dificultan la gestión.

En resumen, todo depende del objetivo de tu aplicación. Simplemente ten claro el objetivo y no te esfuerzes en conseguirlo todo porque será peor. Lo que si que puedes conseguir es un híbrido de sistemas donde parte sea consistente y parte sea disponible, pero jamás los mezcles porque perderan su razon de existencia.

[Mariano Castellano]

Michael, muchas gracias por tu respuesta!. 

Me ha quedado claro que ninguna de las soluciones es mala, solo depende del contexto y necesidades de ese momento. Es muy importante no enceguecerse queriendo aplicar la metodología lo mas estricto posible porque, como dices, al fin y al cabo depende del contexto en el que estemos trabajando.

Ahora me queda pensar que estrategia tomar dependiendo de mi objetivo. En algunas semanas puedo contar que decisión tomé y cuales fueron las ventajas / desventajas de la solución y bienvenido sea el feedback!.

Me has sido de mucha ayuda, al igual que Carlos y Alfredo!. 

Muchas gracias y nos vemos la próxima!

Saludos desde Argentina!

Has recibido este mensaje porque estás suscrito a un tema del grupo "DDD-es" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/ddd-es/cAaSp8fQXDE/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a ddd-es+un...@googlegroups.com.