problema al modelar aggregates
163 views
Skip to first unread message
Paul Ribera
Feb 16, 2012, 1:10:45 AM2/16/12
to DDD-es
bueno queridos amigos soy nuevo y ya ando fregando XD,.
recien me acabo de leer el libro de eric evans DDD, siempre hice laa
DB primero y luego el dominio basado en la DB, ahora tengo una
pregunta ojala se entienda.
tengo una clase usuario la cual es aggregate root, y necesito asociar
estos usuarios a un estado/provincia, el aggregate donde pertence
estado/provincia esta compuesto por las clases pais=>ciudad=>estado,
segun yo esas 3 son 1 aggregate de la cual el root aggregate es pais,
ahora si pongo una propiedad "estado" en la clase usuario estaria
rompinedo la regla "ninguna clase puede referenciar a otra que no sea
un aggregate root o que este fuera de su aggregado", entonces como se
podria modelar esto, si creen que se necesita fotos las pongo si no se
entiende, saludos.
pdd: la clase estado si o si existira en el sistema, ya que servira
para localizar productos.
recien me acabo de leer el libro de eric evans DDD, siempre hice laa
DB primero y luego el dominio basado en la DB, ahora tengo una
pregunta ojala se entienda.
tengo una clase usuario la cual es aggregate root, y necesito asociar
estos usuarios a un estado/provincia, el aggregate donde pertence
estado/provincia esta compuesto por las clases pais=>ciudad=>estado,
segun yo esas 3 son 1 aggregate de la cual el root aggregate es pais,
ahora si pongo una propiedad "estado" en la clase usuario estaria
rompinedo la regla "ninguna clase puede referenciar a otra que no sea
un aggregate root o que este fuera de su aggregado", entonces como se
podria modelar esto, si creen que se necesita fotos las pongo si no se
entiende, saludos.
pdd: la clase estado si o si existira en el sistema, ya que servira
para localizar productos.
Enrique Amodeo
Feb 16, 2012, 2:58:44 AM2/16/12
to ddd...@googlegroups.com
Sin conocer muy bien tu dominio, me lanzó a conjeturar qué el aggregate root no es "país", sino "Lugar", y qué usuario no referencia a "estado", sino a "Lugar", mediante un campo "lugar de residencia" o quizás "lugar de nacimiento".
Salud!
--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a ddd...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a ddd-es+un...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/ddd-es?hl=es.
Marcin Gryszko
Feb 16, 2012, 3:24:05 AM2/16/12
to ddd...@googlegroups.com
Quizas el usuario que estas modelando no pertenece al mismo bounded context que pais/ciudad/estado. Acaso no tienes dos en tu aplicacion: un BC de seguridad y BC producto?
Paul Ribera
Feb 16, 2012, 3:39:14 AM2/16/12
to DDD-es
si agrego una entidad llamada lugar en el aggregate donde esta
pais,estado,ciudad, esta seria el aggregate root, pero en base de
datos supgongo que la tabla usuario haria referencia a ciudad o a
estado, no soy experto soy nuevo en ddd , no he hecho ni mi primer
aplicacion usando ddd.
pais,estado,ciudad, esta seria el aggregate root, pero en base de
datos supgongo que la tabla usuario haria referencia a ciudad o a
estado, no soy experto soy nuevo en ddd , no he hecho ni mi primer
aplicacion usando ddd.
Paul Ribera
Feb 16, 2012, 3:40:52 AM2/16/12
to DDD-es
los BC no me quedan nada claros, pensaba primero jugar con los
aggregates que me parece que son mas importantes, la verdad me mataste
con eso de los BC. soy nuevo en DDD recien estoy tratando de hacer mi
primer aplicacion, antes usaba puro active record.
aggregates que me parece que son mas importantes, la verdad me mataste
con eso de los BC. soy nuevo en DDD recien estoy tratando de hacer mi
primer aplicacion, antes usaba puro active record.
Paul Ribera
Feb 16, 2012, 3:43:00 AM2/16/12
to DDD-es
auanatenme que no hay casi foros ni lugares donde hablar sobre esto.
Marcin Gryszko
Feb 16, 2012, 4:11:23 AM2/16/12
to ddd...@googlegroups.com
Te recomiendo el grupo 'oficial' de DDD de Yahoo. El nivel es muy alto y todo lo que aprendi sobre DDD y CQRS (aparte del blue book) es de este foro.
Marcin Gryszko
Marcin Gryszko
2012/2/16 Paul Ribera <paulr...@msn.com>
auanatenme que no hay casi foros ni lugares donde hablar sobre esto.
José Manuel Beas
Feb 16, 2012, 1:44:13 PM2/16/12
to ddd...@googlegroups.com
¿Dónde vives Paul? Porque si vives en Madrid (España) igual te puedes acercar al grupo de usuarios de Ruby y Rails (madrid-rb) porque me consta que hay gente de nivel haciendo DDD.
Un saludo,
JMB
César De la Torre
Feb 24, 2012, 6:55:31 AM2/24/12
to DDD-es
Hola Paul,
Te recomiendo estudiar esta documentación sobre 'Aggregate Design', by
Vaughn Vernon.
Es un análisis muy bueno de los Aggregate Boundaries, especialmente
basado en las transacciones requeridas, etc.
http://dddcommunity.org/library/vernon_2011
También, si estás trabajando con .NET, puedes ver nuestra
documentación relacionada con patrones DDD y .NET, aquí:
http://microsoftnlayerapp.codeplex.com/documentation
Si trabajas con JAVA, nuestra guía tiene siempre la primera parte de
capítulos en modo genérico (aplicable también a JAVA) y por supuesto,
tienes muchos otros sitios también sobre DDD y JAVA.
Saludos,
César de la Torre.
Architect Advisor
Microsoft
Te recomiendo estudiar esta documentación sobre 'Aggregate Design', by
Vaughn Vernon.
Es un análisis muy bueno de los Aggregate Boundaries, especialmente
basado en las transacciones requeridas, etc.
http://dddcommunity.org/library/vernon_2011
También, si estás trabajando con .NET, puedes ver nuestra
documentación relacionada con patrones DDD y .NET, aquí:
http://microsoftnlayerapp.codeplex.com/documentation
Si trabajas con JAVA, nuestra guía tiene siempre la primera parte de
capítulos en modo genérico (aplicable también a JAVA) y por supuesto,
tienes muchos otros sitios también sobre DDD y JAVA.
Saludos,
César de la Torre.
Architect Advisor
Microsoft
Angel Java Lopez
Feb 24, 2012, 8:37:01 AM2/24/12
to ddd...@googlegroups.com
Hola gente!
Paul, dejando de lado pais, estado, ciudad (supongo que era asi lo que querias modelar pais => estado => ciudad, en lugar de pais => ciudad => estado como escribiste en el primer mail), hay que recordar que podemos tener
A -> B -> C
y que A sea aggregate root, y B tambien un aggregate root, como en la fig 5 del segundo documento del enlace que te recomendaron:
Ahora, volviendo a pais => estado => ciudad
Me confunde un poco. En el primer email, escribias que usuario tiene que tener estado.
En el email de abajo, escribes que usuario "haria referencia a ciudad o a estado". Como es?
En el primer email, escribias:
"a clase estado si o si existira en el sistema, ya que servira
para localizar productos."Eso es mas interesante. Podrias explicar el caso de uso? Que es eso de "localizar los productos". Es ubicarlos, saber donde estan? Porque lo va a usar eso Usuario? En que caso de uso, Usuario interviene, se localizan los productos, y se usa el Usuario.Estado? Por que luego ponias "el usuario podria tener CIUDAD o estado"
Todo DDD se basa mucho en los casos de uso. Si te explayas, podriamos tener mas claro el problema, y quizas la solucion.
Ejemplo: se me ocurren sistemas donde Usuario tiene Lugar, pero cuando compra, esta de vacaciones y quiere que se lo envian a otro lado.
Ejemplo: se me ocurren sistemas donde Usuario es Empleado de una Compania, y es la Compania la que tiene Depositos, y los Depositos tienen lugares, y es ahi donde hay que llevar los productos que Usuario compra para su Compania/Deposito, y hay que ubicar NUESTROS productos mas cercanos a ese lugar final
Pero no tengo idea, de si tu usuario va a comprar, vender, buscar en auto los "productos que hay que localizar"
O entendi todo mal, y "productos a localizar" es "los nombres de los productos tiene que aparecer en el lenguaje de preferencia del usuario". Entonces, se me ocurre:
- No se usa Usuario.Lugar
- Se usa Usuario.LenguajeDePreferencia
Bien puede ser un estadounidense que este viviendo en Buenos Aires, Argentina, y quiere el catalogo en ingles americano, independientemente del lugar en el que esta viviendo, y donde quiere que le envien los productos
O puede que el usuario este en Canada, Ottawa. Como decidir BASADO SOLO EN EL LUGAR, si lo quiere en frances o en ingles? De nuevo, un argumento para descartar Usuario.Lugar para localizar productos.
(Aca en Argentina "localizar" se usa tambien en la acepcion "ubicar")
Nos leemos!
Angel "Java" Lopez
2012/2/16 Paul Ribera <paulr...@msn.com>
Paul Ribera
Mar 13, 2012, 7:42:43 PM3/13/12
to DDD-es
mejor les digo mas o menos lo que se quiere hacer:
1.- se debe tener las ubicaciones de los clientes, para saber en que
ciudad o estado o pais es en el que mas clientes existen.
2.- los compradores deben poder ver la ubicacion del producto(como la
direccion de el producto) tomando la ciudad ,estado y pais.
3.- el punto 2 es para comprar cara a cara, en la cual se defne el
tipo de venta face2face y se define el lugar donde se realizara la
transaccion(venta del producto)
4.- de todas formas igual quiero saber como se asocian ubicaciones a
cualquier cosa(clientes,productos,empresas,etc) sin hacer uso de
objetos valor.
espero me comprendan, saludos.
1.- se debe tener las ubicaciones de los clientes, para saber en que
ciudad o estado o pais es en el que mas clientes existen.
2.- los compradores deben poder ver la ubicacion del producto(como la
direccion de el producto) tomando la ciudad ,estado y pais.
3.- el punto 2 es para comprar cara a cara, en la cual se defne el
tipo de venta face2face y se define el lugar donde se realizara la
transaccion(venta del producto)
4.- de todas formas igual quiero saber como se asocian ubicaciones a
cualquier cosa(clientes,productos,empresas,etc) sin hacer uso de
objetos valor.
espero me comprendan, saludos.
Carlos Peix
Mar 15, 2012, 5:29:32 AM3/15/12
to ddd...@googlegroups.com
Hola Raul,
El punto 4 me dispara el siguiente pensamiento:
La mayoria de los diseños utilizan atributos para el modelado de las direcciones, ya sea que sean atributos o que sea un objeto en si mismo que agrupe los atributos (calle, numero de calle, ciudad, estado, pais, etc.).
Otros pocos, sin embargo, requieren el modelado de las direcciones (a mi me gusta mas el nombre Locacion) como entidades, es decir, una locacion determinada tiene su identidad.
Esa misma locacion debiera usarse como referencia para todo objeto o evento que se considere ubicado en ese lugar.
Incluso puede darse el caso de que una locacion tenga mas de una direccion. Por ejemplo, si creamos la locacion "Casa de Gobierno en Argentina", que se encuentra ubicada en la Ciudad de Buenos Aires, frente a Plaza de Mayo, bien podriamos indicar que tiene la direccion: Balcarce 50, Ciudad de Buenos Aires, Republica Argentina. Pero tiene otra direccion en el numero 24 de la calle Balcarce.
Esto es lo que me ha pasado modelando las locaciones como entidad.
Por otro lado, los puntos 1, 2 y 3, bien podrias resolverlo sin este tipo de modelado, ya sea que trabajes con atributos o con un value object que los agrupe.
----------------------------------
Carlos Peix
El punto 4 me dispara el siguiente pensamiento:
La mayoria de los diseños utilizan atributos para el modelado de las direcciones, ya sea que sean atributos o que sea un objeto en si mismo que agrupe los atributos (calle, numero de calle, ciudad, estado, pais, etc.).
Otros pocos, sin embargo, requieren el modelado de las direcciones (a mi me gusta mas el nombre Locacion) como entidades, es decir, una locacion determinada tiene su identidad.
Esa misma locacion debiera usarse como referencia para todo objeto o evento que se considere ubicado en ese lugar.
Incluso puede darse el caso de que una locacion tenga mas de una direccion. Por ejemplo, si creamos la locacion "Casa de Gobierno en Argentina", que se encuentra ubicada en la Ciudad de Buenos Aires, frente a Plaza de Mayo, bien podriamos indicar que tiene la direccion: Balcarce 50, Ciudad de Buenos Aires, Republica Argentina. Pero tiene otra direccion en el numero 24 de la calle Balcarce.
Esto es lo que me ha pasado modelando las locaciones como entidad.
Por otro lado, los puntos 1, 2 y 3, bien podrias resolverlo sin este tipo de modelado, ya sea que trabajes con atributos o con un value object que los agrupe.
----------------------------------
Carlos Peix
2012/3/13 Paul Ribera <paulr...@msn.com>
Reply all
Reply to author
Forward
0 new messages