DDD y CQRS: Preguntas Frecuentes

🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
⮕ codely.tv/pro/blackfriday?utm...
---
Respouestas a dudas surgidas a partir del vídeo sobre DDD y CQRS. Preguntas o posibles planteamientos alternativos que también nos surgieron a nosotros al empezar con Domain-Driven Design y Command Query Responsibility Segregation. Más info: codely.tv/screencasts/ddd-cqrs...

[@CodelyTV]

Ya disponible el curso de CQRS completo donde entramos mucho más en detalle y lo ilustramos con ejemplos de implementación tanto en PHP como en Scala. Más información: pro.codely.tv/library/cqrs-command-query-responsibility-segregation-3719e4aa/62554/about/

[@FPontiDev]

Gracias por vuestros vídeos. Enhorabuena!

[@d-landjs]

Excelente video amigos!!!

[@davidpccode]

Que pros!

[@francescocavallari7841]

Video super útil e interesante. Tengo unas preguntas: cuando habláis de delegar al cliente la responsabilidad sobre el UUID del recurso a crear, como lo planteáis a nivel de API? Imaginando que el caso de uso es crear un Post de un blog: el recurso a nivel de API incluye el UUID y nos esperamos que haya un endpoint POST /posts que en el body tenga el UUID? O pedimos un PUT /posts/{uuid}? Y cuando definimos el GET /posts/{uuid} en el body de la respuesta vuelve a aparecer el uuid como parte de la definición de ese recurso? Cual sería vuestra propuesta ideal? Gracias y enhorabuena!!

[@kmilo93sd]

Saludos, geniales sus vídeos, he aprendido un montón con ellos. Deberían hacer unos cuantos videitos sobre patrones de diseño y cuando usarlos correctamente. De pronto podrá ser algo de novatillo tal vez, pero tienen una facilidad tremenda para explicar.

[@CodelyTV]

Para nada es algo de novato! De hecho en el último vídeo puedes ver cómo usamos algunos patrones de diseño para hacer el código más legible: kzbin.info/www/bejne/qpDKgat3mqhmqMU 🙂 ¡Saludos!

[@kakenn20]

Eso de dejar el metodo vacio es un poco smell no? Tiene toda la pinta de estar aplicando mal la herencia

[@thevolcomstone10]

Buen video, apenas estoy intentando aprender todo esto y no se por donde comenzar, que me recomiendan.

[@CodelyTV]

¡Buenas! Si te interesan estos temas, te recomendamos los vídeos de: * Introducción a Arquitectura Hexagonal: kzbin.info/www/bejne/fYucmpZvhriCa7c * De código acoplado al framework hasta microservicios pasando por DDD: kzbin.info/www/bejne/pWHaXp2PqtNpd7c * Si programas en PHP, el libro "DDD in PHP" también te puede ser de ayuda :) * Más vídeos en proceso!

[@joecolmer7292]

con lo de crear el Id desde código, que pasa con la concurrencia. También, otra cosa, es muy improbable que se repita, pero y si se repite? Mas que nada pensando en el Murphy... No creo que sea una buena práctica lo de crear ids para que los tests sean mas fáciles, los tests, no son la aplicación, no se si me explico.

[@gcaqp]

17:20 pero se puede hacer un MockService o MockBus Tranquilamente para que no suceda eso... aislas la funcionalidad de ese raiseEvent y que da pruebas lo puntual sin afectar a lo demas, tan secillo como eso

[@mauricioelliff4117]

Yo creo q pondría una variable global q de estar con valor TEST, omitiera el lanzado de eventos

[@mauricioelliff4117]

.... O ampliando, haría esto. Cada capa del dominio tendría su extend abstract, así tendría una clase para implementación, infraestructura, o como quiera subdividirse los casos de uso y nuestros test, luego entonces si, tendría la variable global q indicaría q parte se está testeando y el código sabría q funcionalidad deberá ejecutarse o omitirse.

[@alexandervidaurrearroyo3151]

10:15 tenia entendido que en DDD el controlador pertenece a la capa de presentacion, no a la de aplicacion 4:10 Otra cosa que tenia entendido es no usar excepciones ni para las validaciones ni para la logica de negocio o para el control de flujo en general. "Deja las excepciones para situaciones excepcionales". Por ultimo, ¿usar un uuid como clave primaria (o cualquier campo no numerico) no disminuye el rendimiento de las consultas que requieren joins?

[@hazelhumor]

Hola, aunque ya ha pasado un año y quizás ya has resuelto tus dudas, creo que puedo aportar algo al respecto. 1) Cuando hablan de "aplicación' en 10:15, no se refieren a la capa de "Aplicación" de Arquitectura Hexagonal, sinó más bien al típico directorio "apps" que contiene los puntos de entrada (i.e. controllers) y otros ficheros de configuración del propio framework o de otros bundles. 2) En cuanto a lo de las UUIDs y el bajo rendimiento al hacer joins, CQRS es tu amigo. Uno de los grandes beneficios de CQRS es que dispones de un modelo de escritura y varios de lectura. La clave está en el modelo de lectura, puesto que está tan "denormalizado" como necesites para facilitar las consultas de búsqueda, minimizando el número de JOINS, haciendo que solo sean necesarios de forma excepcional, ganando así bastante rendimiento. Imagina que en un modelo relacional de toda la vida tienes "user" y "user_info" dónde "user_info.user_id" es una FK a la tabla "user". Para buscar la info por DNI, desde un punto de vista "tradicional", tendrías que hacer un JOIN entre ambas tablas, pero con CQRS simplemente tendrías una única tabla (modelo de lectura) con TODOS los campos de "user" y "user_info". Ahí te ahorras el JOIN. De hecho, si al trabajar con DDD tus consultas suelen tener muchos JOIN, suele ser un síntoma de que el dominio no está bien modelado y hay que segregar más entre modelo de escritura y modelo de lectura.

[@alexandreicasuriaga9850]

Hola, He estado estudiando vuestro proyecto (github.com/CodelyTV/cqrs-ddd-example/) y me surgen las siguientes dudas: Por cada entidad creáis un bundle (CodelyTv\Context\Video\Infrastructure\Symfony\Bundle) que puede contener diferente conexión a bd? Gracias por vuestros vídeos!

[@mcarra66]

¿que opináis de usar MongoId en lugar de UUID como identificador único?

[@mcarra66]

Yo me refiero a la unicidad que te da MongoId vs UUID. Mediante el driver de mongo en PHP puedes hacer un new \MongoId() i persistir después en base de datos usando ese objeto, sin necesidad de flushear para saber que MongoId te ha generado la base de datos.

[@mcarra66]

eso es cierto...tal vez ese es el motivo que hace que no sea aconsejable usar \MongoId como identificador único. gracias!

[@CodelyTV]

Realmente el principal beneficio que se busca aquí es poder generar los identificadores desde el exterior de nuestra aplicación, y no desde la infraestructura como sería el caso de IDs autoincrementales. Buscamos este beneficio principalmente por testing tal y como se explica en el vídeo :) @Dani va bien encaminado, pero aún así, podríamos pensar en usar la implementación de \MongoId como adaptador de esos identificadores en vez de una librería de UUIDs. Aquí el voto personalmente seguiría yendo para UUIDs. Es un formato más estándar que incluso algunas bases de datos y lenguajes ya reconocen como tipo primitivo. Además, se hace más fácil encontrar soporte en otros lenguajes como por ejemplo JavaScript, en vez de MongoIds :)

[@DLuffyPaul]

esta muy bajo el audio :(

[@bonaoenchelcha]

estos conceptos me parecen tan confusos :(

[@gcaqp]

16:50 mi punto de vista es que utilizar un ORM es una metida de pata que comunmente sucede, pierdes control de tu sentencias, Solo quiza para manipulacion de datos (IUD) pero nunca para recuperar datos. Ademas hacerlo por reflection, consume mas procesador, prefiero la programacion mas tipada

[@FiliusDeiPatris]

Giancarlo Huarcaya Pero si cambiar la bd es transparente gracias a usar un orm

[@SimaDamian]

@@FiliusDeiPatris Es la teória, pero en la práctica depende mucho... si es necesaria esa potencial facilidad para cambiar de db. Por otro lado la base de datos debería estar desacoplada, tanto en interfaz de consulta como de modificaciones

[@dvddavizcky3254]

hablen más duro pls

[@dmsanz_youtube]

Buen programa chicos. Si me lo permitís, para los programadores .NET he creado unos vídeos explicando cómo implementar Event Sourcing desde cero sin utilizar ningún framework ni librería. Event sourcing complementa a CQRS a la perfección hasta el punto en el que como bien decís se puede usar CQRS sin event sourcing pero no se puede usar Event Sourcing sin CQRS (o digamos que no sería práctico) Aquí dejo información de lo que es event sourcing y de lo sencillo que es su implementación. A vuestra disposición si le veis utilidad! Parte 1 de 3 (teoría): kzbin.info/www/bejne/mqiZhX-mZ9x3ndU Parte 2 de 3 (implementación de componentes de event sourcing): kzbin.info/www/bejne/e3qthZppg7F7lbs Parte 3 de 3 (implementación de demo): kzbin.info/www/bejne/p3-9XpKZd6Z2oZo

[@victorpanchuk1824]

лучше б на русском вещали