El patrón CQRS en la arquitectura microservicios |

แชร์
ฝัง
  • เผยแพร่เมื่อ 4 ธ.ค. 2024
  • CQRS son las siglas de Command Query Responsibility Segregation o Separación de las responsabilidades de comandos y consultas.
    Es un patrón de diseño que favorece la separación de la lógica de escritura en una aplicación de su lógica de lectura. Permitiendo escalar las necesidades de escritura y lectura de forma independiente.
    ✅ Aprende más en nuestro blog: sacavix.com/
    ✅ Apóyanos en Patreon: / sacavix_tech
    (Con tu apoyo en Patreon accedes a ventajas exclusivas como directos, preguntas y respuestas en el chat, respuestas a tus dudas y acceso a nuestro libro "Patrones para la implementación de una arquitectura basada en microservicios".
    CQRS tiene retos importantes en su implementación y diferentes variantes. En este video aprenderás:
    ¿Qué es CQRS ?
    ¿Por que surge CQRS ?
    Ventajas de usar CQRS.
    Variantes posibles de CQRS.
    Recomendaciones para implementar CQRS.
    Dificultades y problemas de implementar CQRS
    Ejemplo en Java y Spring Boot de CQRS.
    Espero te guste el video.
    #cqrs #microservicios #distributed #microservices #patterns

ความคิดเห็น • 18

  • @jhonmeneses6837
    @jhonmeneses6837 3 หลายเดือนก่อน

    Que buen video, por fin despues de tanto tiempo logro entender el funcionamiento de este patron, lamentablemente o afortunadamente no le veo uso en mi dia a dia de trabajo debido a la simplicidad de requerimientos.

  • @arceliomontezuma3458
    @arceliomontezuma3458 2 ปีที่แล้ว +3

    Espero un dia tener tanto conocimiento, gracias por toda la informacion

  • @ricardotilleriaochoa5674
    @ricardotilleriaochoa5674 2 ปีที่แล้ว +1

    Excelente explicación, gracias por compartir la información

  • @jibaris
    @jibaris 2 หลายเดือนก่อน

    Creo es fundamental eso que dijiste de "cuándo NO usar CQRS". CQRS sólo tiene sentido si a la hora de escribir/actualizar los datos se requieren de múltiples bloqueos (por ej, bloqueos en múltiples tablas de una RDB) que impidan la concurrencia. Hasta ahora no he dado con un caso así en mi experiencia laboral pero, por supuesto, depende de cada negocio.

  • @miiid._.
    @miiid._. 2 ปีที่แล้ว +1

    Gracias por tu contenido y aportación a la comunidad! Tengo unas dudas, espero alguien me pueda orientar de favor. Hablando de microservicios (comunicación vía mensajes, EDA, CQRS, database per service…), teniendo por ejemplo un servicio de pagos y uno de usuarios ¿Cómo podría hacer una query del sistema de pagos al de usuarios para validar que un user está mandado dinero a otro user existente? No sé si sea buena idea comunicarnos con rest por temas de disponibilidad, ya que afectaría a la integridad de datos si utilizáramos patrones de resiliencia para dar una respuesta alternativa cuando un sistema no se encuentra disponible (¿Tendría que reencolar el mensaje de nuevo en mi sistema de mensajería hasta que el servicio donde mando la solicitud de obtención de datos esté disponible? ). Lo que se me ocurría era publicar un evento al registrar un user para que el sistema de pagos lo capture y lo tenga en su propia base de datos (lo cual nos lleva a mucha duplicidad de data a futuro), el tema de esto es que si el día de mañana quiero desarrollar otro servicio que tenga la misma información que el de usuarios, sería un problema ya estando en producción si estos sistemas tienen una alta demanda de tráfico aun haciendo replay de todos los eventos del event store.
    De igual forma pensaba que si el sistema de usuarios agregara nuevos campos que requirieran los demás sistemas ¿Cómo se igualaría esa información? La otra duda sería en caso de que esto que digo sea válido ¿Siempre deberíamos de replicar toda la data de un servicio a otro (por ejemplo en este caso replicar toda la información de un usuario en la base de datos de pagos)?
    A pesar de que esto es agnóstico a lenguajes o tecnologías, yo que estoy más acostumbrado a Java tengo entendido que esto sería más sencillo (por decirlo de algún modo) con herramientas o Frameworks como lo es Axon, el tema de esto es que cuando tienes tus servicios distribuidos en distintos servidores esto se vuelve de paga, a pesar de que ensuciaría mi dominio siendo referente a DDD y clean arquitectures.

  • @franciscoespinosagonzales2331
    @franciscoespinosagonzales2331 2 ปีที่แล้ว

    Bueno este video... saludos de Montevideo... jj

    • @SACAViXTech
      @SACAViXTech  2 ปีที่แล้ว

      Muchas gracias! 😊

  • @jordanalbano5191
    @jordanalbano5191 4 หลายเดือนก่อน

    Buenisimo!. pero me quedo una duda, si bien decis que no devuelven informacion, si uso un controller, y este retorna un codigo de estado al frontend, este codigo de estado si se podria enviar?
    Cuando decis que no devuelve informacion te referis a la informacion de la entidad? Saludos .

  • @marcoantonioencisosalinas6437
    @marcoantonioencisosalinas6437 ปีที่แล้ว +1

    Como se manejan las excepciones usando este patron, es decir que pasa si falla el command al crear la operacion de escritura, como se manejan esas excepciones. Gracias

  • @hanya201087
    @hanya201087 2 ปีที่แล้ว

    excelente como siempre, me puedes orientar donde puedo conseguir buena información y material, con ejemplos prácticos sobre el patrón saga , compensaciones en sistemas distribuidos o microservicios. gracias por el vídeo.

    • @SACAViXTech
      @SACAViXTech  2 ปีที่แล้ว +1

      Hola Ali, en realidad encontrar todo en solo sitio esta difícil a veces de encontrar, pero pronto haremos algo sobre SAGAs. Ahora casualmente esta semana saco en la serie "Aprende los conceptos" el concepto de "Acción compensatoria" y "Transaccion distribuida", porque ando en ese camino justo, preparando el publico para entrar luego en SAGA :-)

    • @hanya201087
      @hanya201087 2 ปีที่แล้ว

      @@SACAViXTech perfecto estaré pendiente.

  • @alejandrosantana4259
    @alejandrosantana4259 ปีที่แล้ว

    que alegria encontrarme un cubano explicando estos temas, por fin puedo abandonar los tutoriales indios 😂. Muy buen video.

  • @UnDevMas
    @UnDevMas 9 หลายเดือนก่อน

    Hola, sabes porque se usa AXON y todoe ste tema podria implementar CQRS sin necesidad de usar AXON ?

    • @SACAViXTech
      @SACAViXTech  9 หลายเดือนก่อน

      Hola, si es posible sin AXON, la ventaja de AXON es que integra tecnologías para hacerlo fácil, pero no es requerido, usando un bus de mensaje como Kafka, Rabbit, SQS u otro puedes implementarlo.

    • @UnDevMas
      @UnDevMas 9 หลายเดือนก่อน

      Quiero hacer eso sin usar Axon, y usare weblux, lo que tengo pensado es esto: creare 2 bus 1 para los commands y 1 para los DomainEvents, la idea es que el bus de commands reparta estos eventos para los manejadores especificos, segun la clase o el tipo de comando , pero lo que no entiendo es donde haria esto, en el command handle hago como el publish a mi event bus y ya retorna como un Ok qya que sera asincrono?m y ya leugo en el listener es donde llamo a la bd? esto seria correcto?, y para actualizar la BD desde ese listener del command hago un publish cuando se guarde el regfistro de la bd como un domainEvent, para actualizar con la info de la bd de lectura enviando a un rabbit o kafka o algo pro el estilo ?
      ? ,o esto seria incorrecto ? @@SACAViXTech

    • @UnDevMas
      @UnDevMas 9 หลายเดือนก่อน

      Otra duda, crees que sea necesario usar un bus para manejar los commands usando webflux y arquitectura hexagonal?, porque yo no le veo mucho sentido porque 1. las operaciones con webflux ya son asyncronas, 2. ya encabsula la logica de negocio en el dominio , entonces tengo la duda es realmente valdria la pena poner un bus de commands para manejar estas operaciones de insercion o podria simplemente separar los query de los command y no violaria el patron CQRS? para este caso con webflux y arch hexagonal?
      @@SACAViXTech