tutorial example driven domain ddd architecture domain-driven-design cqrs dddd

architecture - example - Alternativas a las relaciones muchos a muchos con CQRS



domain driven design example (1)

Supongamos que ambos son agregados, copie los datos de autor que necesite en el agregado del libro al agregar el nuevo libro para que los comandos posteriores tengan suficientes datos de autor para trabajar. Ahora, si el agregado del autor necesita información sobre los libros escritos por el autor, podría "suscribirse" al evento NewBookAdded (técnicamente podría enviar un comando RegisterAsAuthorOfBook al agregado del autor como resultado del evento NewBookAdded). Supongo que uno podría modelar esto al revés también, pero no soy tan íntimo con el dominio del autor del libro.

La conclusión es que realmente no se almacena de muchos a muchos porque no se escalan. Tienes que empezar a pensar en ellos (agregados) como enviar mensajes entre ellos. La pregunta más importante es qué debe ser consistente y en qué momento debe ser consistente. ¿Nos importa que el autor no refleje instantáneamente el hecho de que se haya agregado un nuevo libro, del cual él / ella es el autor? ¿Hay alguna invariante que el Autor quiera imponer con respecto a los libros que ha escrito (y viceversa)?

Otra cosa es dejar de estar orientado a los datos y más orientado al comportamiento. ¿Cuál es el comportamiento del agregado Libro y Autor? Esto le dirá qué datos se requieren y en qué punto se debe modelar.

http://pastie.org/1220582 para una primera puñalada en el agregado del Libro.

¿Cómo modelamos las relaciones clásicas de muchos a muchos con CQRS / DDD?

Sé que las implementaciones y soluciones DDD y CQRS tienden a ser específicas del dominio, por lo que puede ser difícil encontrar una respuesta general a esta pregunta.

Sin embargo, supongamos que tenemos la relación familiar entre Libro y Autor . Esta es una relación clásica de muchos a muchos.

Para mí, parece más natural que el Libro y el Autor sean dos Entidades diferentes que cada una pertenece a su propia Raíz Agregada . Por lo tanto, modelar explícitamente la relación de muchos a muchos entre ellos no es el camino a seguir.

¿Cómo modelamos un AddBookCommand? Queremos poder agregar un libro a nuestra biblioteca, y también de alguna manera indicar que un Autor en particular escribió este Libro . ¿Cómo modelamos (y persistimos) tal relación?

Ni el Libro ni el Autor parecen ser buenos candidatos para Value Objects ...