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!
--
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.
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.
Gracias y saludos!
Mariano.
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.
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.
--
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.
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?.
--
--
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.
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!!
--
--
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.
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.
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.
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.
--
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.
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.