El problema del DDD: Unir información de varias Entidades (Read vs Write Model)

Uno de los mayores problemas con el Domain-Driven Design, es unir información de diversas entidades. Por ejemplo productos y categorías. En este vídeo exploramos el problemas y encaramos una solución.
Aprende más sobre este caso en el curso → cdly.to/caso-a...
﹤🍍﹥ Codely
├ 🎥 Suscríbete: kzbin.info...
├ 🔖 Cursos: bit.ly/cursos-...
└ 👋 Redes sociales:
├ / codelytv
├ / javiercane
├ / rafaoe
├ / codelytv
└ / codelytv

Pues igual este es el curso que me faltaba para ver claro como implmentar en mis proyectos el DDD porque una de mis grandes dudas era como hacer los agregados bien porque menudo carajal me generaban :D

[@ltroya]

Interesante el video, aunque si me hubiese gustado que volvieran al ejemplo de la pagina de amazon y evaluar el endpoint que se iba a consumir para solventar esa necesidad. Por cierto, que tema es el que estan usando en su editor?

[@jahbless8244]

Excelente video, tengo una pregunta, si tengo un proyecto con los modulos User y Article actualmente al momento de hacer la peticion hacia /api/articles/{id} utilizo los repositorios tanto de article como de user y devuelvo el objeto {...article, user: {...}} este enfoque es viable, o deberia optar por hacerlo en peticiones separadas como mencionan en el video, teniendo en cuenta que Article cuenta con la propiedad userId. Cualquier comentario es bien recibido.

[@thrashgamingpc3155]

Según tengo entendido los finders devuelven value objects o modelos mas orientados a la lectura y los repositorios suelen devolver entidades de dominio o agregados que contienen lógica y mutabilidad. Me ha parecido un poco extraño que un finder sea una pieza de aplicación donde tiene inyectado un repositorio. En mi empresa, cuando queremos hacer lecturas (conceptualmente una Query de CQRS) las queries (application) contienen finders que devuelven modelos de lectura (value objects). En caso de que el value object no haya podido absorber los suficientes datos, los orquestamos en la query y creamos un DTO con los datos compuestos de varias fuentes. De esta forma a nivel de base de datos sigue siendo mas liviano que traer un agregado gigante y consigues tener la respuesta al cliente en una sola query.

[@renhabbo5502]

boa increible video, gracias!!!

[@Jefferson4026]

El módulo para lectura no debe tener agregado? Sino al ser como un readmodel directo llama al repositorio desde el caso del uso sin tener que usar agregafos? Y eso de toPrimitive se puede tener en un agregado? Para luego si quiero llevarlo a un dto me permita extraer el estado de la entidad ?

[@franciscogonzalezlinares7518]

Maestros!!

[@titobundy]

Excelente contenido de sus videos, aunque van como 1x5, le vuelvo a ver para entender el concepto y el código, están muy relacionados a mis intereses, me gustaría ir tomando los cursos pero no se si ¿tienen algún roadmap de acuerdo a ciertas temáticas, por r ejemplo clean, arquitectura? , ya que me desorienta un poco en sus videos de KZbin, que hace varias referencias cruzadas a otros cursos,, sería ideal ese roadmap para que sirva de guía de como ir tomando los cursos y ampliando tus conocimientos base para otros, un saludo y muchas gracias

[@CodelyTV]

Aquí tienes 😊 soporte.codely.com/es/articles/4187948-en-que-orden-hacer-los-cursos

[@JoseManuelLigeroMarquez]

Al final no han explicado la manera correcta y eficiente de hacer el agregado, perdida de tiempo.

[@PeeledBanana-c8i]

De hacer los agregados si. El problema subyacente es utilizar el modelo de escritura como modelo de lectura tambien para todo. Lo que han hecho en el video es separar el agregado gigante que tenian en pequeños agregados más mantenibles y con más sentido. Esto ahora tiene otro "problema" que es que donde antes hacías una petición, ahora haces 3. Las posibles soluciones a esto es lo que no han explicado en el video porque al final les interesa que vayas a su curso por supuesto.

[@ivansurveys3622]

Al final la idea también es la de animar la gente a comprar su suscripción!!! Nadie trabaja de gratis...

[@JoseManuelLigeroMarquez]

Yo os lo digo, con un QueryBus que en ultima instancia agregue los 3 dominios a la altura del controller. O haciendo proyecciones en base de datos cuando se ejecutan los Command y luego tirar una sola query. Basicamente aplicando CQRS correctamente. Abiertos a debate.

[@diegodig9]

Tendrán que cobrar por su trabajo vendiendo cursos no?

[@4strodev]

18:15 ¿esto no se solucionaria tambien con test containers?

[@tumacho-d9t]

El problema es que quieren aplicar estas 'nuevas modas' clean architecture, ddd, tdd, etc etc...que no sirven pero te la venden que sirven. Siempre hay que pensar en la simplicidad. 😂😂😂 Dan pena los nuevos arquitectos xd

[@ivansurveys3622]

No es una moda, con todos mis respetos o no te has enfrentado a entornos de gran concurrencia y alta disponibilidad al cambio o bien no quieres verlo...