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.
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?
Seguro que es una tontería pero no lo veo ya que no controlo typescript pero si creamos la entidad producto por constructor desde el exterior no se emitiría el evento... entiendo que la creacción del objeto sea siempre por el metodo create pero no termino de verlo :(
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.
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.
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í.
![일상 속 기분 좋음 [Proto disco meme]](http://i.ytimg.com/vi/DwmEIaZ7XGQ/mqdefault.jpg)
Me han dicho que aquí explican más cosas sobre los Agregados 👀 bit.ly/curso-agregados 👀
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 🙌
Últimamente tengo la impresión de que se les está yendo la pinza a los arquitectos de software.
Como siempre, impecable! De las mejores explicaciones que he visto del Aggregate y Aggregate Root!
Viendo esto y siendo frontend , me pregunto por que a la gente le gusta más la OOP que funcional.
Pagan más
Excelentee! muchisimas graciiias 🧡🧡🧡🧡
jajaj cracks! .. escucharlos a este ritmo de bpm tan informativo ! graciaas !
Mola mucho, seguid con las explicaciones
Videazo. Gran explicación.
Fuaaa tremendo 🙌
videazo, que bueno!!!
Buenisimo video, gracias por este material
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.
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.
Seguro que es una tontería pero no lo veo ya que no controlo typescript pero si creamos la entidad producto por constructor desde el exterior no se emitiría el evento... entiendo que la creacción del objeto sea siempre por el metodo create pero no termino de verlo :(
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.
Muy bueno...
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í.
Like por el churrazo de código
Porque Rafa parece un NPC al principio? xd