DDD Agregados vs Entidades: Explicación en Detalle
Vložit
- čas přidán 13. 09. 2023
- Cuando se empieza en el mundo del DDD, una de las primeras cosas que se aprende es la diferencia entre Entidades y Value Objects. Unos tienen identificadores y los otros no.
Pero llega el punto donde nuestro dominio no es tan simple y queremos poner una Entidad dentro de otra. Allí es donde entran en juego los Agregados y lo que vamos a ver en este vídeo.
Curso de Agregados: bit.ly/curso-agregados
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🧔🏻 Twitter Javi: / javiercane
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🥋 Academy: codely.com/academy
└ 📕 Catálogo cursos: bit.ly/cursos-codely - Věda a technologie
Me han dicho que aquí explican más cosas sobre los Agregados 👀 bit.ly/curso-agregados 👀
Últimamente tengo la impresión de que se les está yendo la pinza a los arquitectos de software.
Gracias, se agradece que nos hayan dejado con mas dudas :(
😄
Maravilla!!! Cómo se nota la evolución en este curso!!!! Este es el camino! Grandes 🎉🎉🎉
Ese Mikaaaaaaa!! Mil gracias 🙌
Como siempre, impecable! De las mejores explicaciones que he visto del Aggregate y Aggregate Root!
Excelentee! muchisimas graciiias 🧡🧡🧡🧡
Videazo. Gran explicación.
jajaj cracks! .. escucharlos a este ritmo de bpm tan informativo ! graciaas !
Mola mucho, seguid con las explicaciones
Buenisimo video, gracias por este material
videazo, que bueno!!!
Fuaaa tremendo 🙌
Viendo esto y siendo frontend , me pregunto por que a la gente le gusta más la OOP que funcional.
Muy buena explicación! Me encanto! Tengo una duda, hay algun camino que nos pueda llevar a q "Reviews" sea un microservicio? Suponiendo que esto es realmente complejo, ya que maneja comentarios, calificación, hasta dentro puede tener un black list de usuarios.
Otra pregunta: ¿El Agregado PRODUCTO puede existir en varios contextos distintos? ¿Cómo se maneja?
No es lo mismo un PRODUCTO en una compra que un PRODUCTO en un balance.
DDD No he llegado aún a esa parte del libro, pero sí hay que leerlo con calma, y tomarse un tiempo en reflexionar lo aprendido....Dejando de un lado al DDD, y hablando del diseño de las clases, la clase solo debe hacer lo que le corresponde por tal motivo estoy de acuerdo la clase de llame Producto, Recordemos que un entidad no se encarga de procesar y gestionar datos, ya que para eso se encuentra la clase ProductoRepository.
Muy bueno...
Una pregunta: ¿La autenticación me confunde en DDD?. EN el dominio busco el usuario y la contraseña en el repositorio? O lo busco en la capa de aplicación?
El dominio sólo establece los ValueObjects y la interfaz del repositorio o también el dominio evalúa la contraseña?
Estaría bueno que hagan un video sobre autenticación de usuario con jwt en DDD. Me tiene muy confundido ese tema.
Like por el churrazo de código
ese crecimiento tanto horizontal como vertical suena a que metes todo dentro de una bolsa a medida que el sistema crece, no le encuentro la escalabilidad al enfoque DDD al menos con su explicación.
Porque Rafa parece un NPC al principio? xd
Y si hay 25k reviews, vas a cargar los 25k en memoria cuando haces un fetch de un producto o cuando quieras agregar un review?
Creo que en este caso hay varias estrategias para abordar este problema. Podrías decidir que tu agregado contenga como reviews simplemente el número de reviews, que es por ejemplo lo que se ve en amazon en los productos a primera vista y si acaso la puntuación media de estas reviews. Y luego si se pulsa en reviews, puedes empezar a cargarlas de forma paginada o bien montar un agregado aparte de las reviews para no tener que montar toda la lógica en el agregado de los productos. La forma de comunicar luego distintos agregados puede ser con eventos de dominio si te vale la consistencia eventual. Si se complica mucho la cosa, tal vez podrías incluso montar un servicio de dominio que encapsule cierta lógica que atañe a diversos agregados. También puedes considerar el anidamiento de agregados. Desde un agregado tiras contra operaciones del otro agregado y el agregado interno ya se encarga de implemntar los detalles.
No noto la diferencia conceptual entre imagenes y reviews
Hay que tener en cuenta que cuando diseñamos un sistema, se hace de acuerdo a las reglas de dominio. En este caso, de acuerdo a las reglas del dominio, imagenes quedó como VO y reviews como entity. Eso significa que las imágenes no van a tener un identificador por lo que las hace immutables y eso está bien, porque hace match con las reglas de dominio.
En otros sistemas podría ser al contrario o las dos como entities y así.