[Consulta] Entidades con grandes colecciones

[Mariano Castellano]

Buenos días a todos, como andan?

Modelando un problema mediante el enfoque DDD me tope con un problema. Entidades con se componen de colecciones pero estas pueden ser muy grandes. 

En mi contexto, un juego, un Jugador tiene Cartas coleccionables. Estas cartas se van adquiriendo a medida que el Jugador va respondiendo preguntas. Las cartas inicialmente son pocas, pero potencialmente podrían ser miles, es poco probable pero puede ocurrir. 

Lo que se me ocurrió es modelar un Aggregate Jugador el cual posee un Álbum que es el encargado de manejar las cartas, ya que cuando un Jugador obtiene una Carta pasa a tener otras propiedades, como por ejemplo, la cantidad de repeticiones que tiene de dicha carta.  

Según el libro de Vaughn Vernon hay que tratar de evitar las colecciones que pueden ser potencialmente grandes, es decir, evitar las relaciones 0..N siempre que se pueda.

El problema ocurre en la persistencia. Al querer hacer algún cambio en el Jugador, mínimo tal vez, ya que tiene otras propiedades, tendría que traerme siempre toda esa colección y volver a guardar, siendo esto muy costoso.

Se les ocurre alguna estrategia para mitigar un poco este problema?. 

Muchas gracias, y saludos desde Argentina!

Mariano.

[Diego Fontdevila]

Un patrón posible es Value List Handler, encontré este link, no estoy seguro que sea lo mejor

http://www.oracle.com/technetwork/java/valuelisthandler-142464.html

Diego

--
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.

--

Diego

@dfontde

[Carlos Peix]

2015-07-16 14:06 GMT-04:00 Mariano Castellano <castellan...@gmail.com>:

Según el libro de Vaughn Vernon hay que tratar de evitar las colecciones que pueden ser potencialmente grandes,

Esto lo entiendo...

 

es decir, evitar las relaciones 0..N siempre que se pueda.

...pero esto no.

Si N fuese máximo 4, por ejemplo, como es que aplicás la regla anterior a este caso? Vernon recomienda las colecciones que puedan tener grandes cantidades o cualquier colección (aunque el maximo fuese 4)?

 

El problema ocurre en la persistencia. Al querer hacer algún cambio en el Jugador, mínimo tal vez, ya que tiene otras propiedades, tendría que traerme siempre toda esa colección y volver a guardar, siendo esto muy costoso.

No siempre, con un buen ORM bien configurado, no es necesario cargar toda la colección para agregar un ítem.

Digo esto como respuesta directa a tu pregunta, sin analizar si la colección es un buen modelado o no.

[Paul Ribera]

yo creo que en DDD una entidad compuestas por colecciones que son colecciones de otro tipo de entidad sele llama aggregate, y no creo que DDD sea bueno para aplicarlo en juegos, creo que es mejor para aplicaciones empresariales, y cuesta mucho realizar DDD, yo acabe tirando la toalla con DDD ya que parece que a todos mis proyectos no puede adaptarlo, quedaba muy forzado y como bien dice el creador de esto es que DDD se aplica a muy pocos casos creo que decia al 5% de todas las aplicaciones, saludetes.

[Mariano Castellano]

Diego, voy a leer el patrón que me sugerís, tal vez aplique.

Carlos, Vernon lo recomienda para colecciones con gran cantidades de elementos. Tal vez no me expresé bien.

Paul, voy a seguir leyendo sobre DDD y tratar de no forzarlo, ya que como bien decis, puede que no siempre aplique.

Gracias a todos por las respuestas!. Me han dado puntas para seguir investigando!

Saludos!

Mariano.

[Michael-Jorge Gómez Campos]

Y si tu listado solo se compusiera de ids de cartas? Doy por supuesto que cada carta tiene un identificador unico. Aunque en tu entidad cargaras toda una coleccion de ids tampoco pasaria nada y vamos soy muy escepyico si creo que vayas a tener millones de cartas... que podria ser!! Tu piensa que todo lo que dices luego (cambian las propiedades como cuantas veces se repite una carta...) estas agregando funciones de reporting al dominio. Podrias tener un objeto de reporting que represente las estadisticas de cartas que tenga el jugador. Otra cosa que podrias hacer es que, en vez de que el jugador tenga un album de cartas, que la carta tenga un dueño/album asociado. De esta forma solo cargas la info de la carta y le asignas un usuario. Todo esto funciona si y solo si las cartas tienen un id unico (guid).

--