Segregación de responsabilidades de comandos y consultas

En los sistemas empresariales modernos , la creciente complejidad arquitectónica ha planteado importantes desafíos relacionados con la escalabilidad, el mantenimiento y el rendimiento en tiempo de ejecución. Las implementaciones de la Separación de Responsabilidades de Comandos y Consultas (CQRS) y los diseños orientados a eventos suelen integrar la lógica empresarial central con aspectos transversales como el registro, las políticas de reintento y la propagación de auditorías. ^{[ 2 ]} Esta combinación puede dar lugar a componentes estrechamente acoplados, lo que reduce la modularidad y complica la evolución a largo plazo.

Los marcos CQRS modernos buscan desacoplar estos aspectos operacionales de la lógica de dominio para mejorar la adaptabilidad del sistema. Basándose en principios de diseño establecidos, como los patrones Cadena de Responsabilidad y Estrategia ^{[ 3 ]} , junto con paradigmas de programación declarativa , CQRS modela el procesamiento de comandos como una tubería funcional ^{[ 4 ].}${\displaystyle P}$Cada etapa de procesamiento${\displaystyle s\in S}$(por ejemplo, enrutamiento, ejecución de middleware, invocación de manejadores o posprocesamiento) se coordina a través de cadenas de interceptores dinámicamente extensibles.${\displaystyle I}$.

Este enfoque arquitectónico ^{[ 5 ]} está diseñado para proporcionar latencia predecible, alto rendimiento, ^{[ 6 ]} seguridad de tipos sólida , ^{[ 7 ]} y características de idempotencia confiable, lo que lo hace adecuado para aplicaciones distribuidas a gran escala resilientes. En tecnología de la información , la Segregación de Responsabilidad de Comando-Consulta (CQRS) es una arquitectura de software que extiende la idea detrás de la separación de comando-consulta (CQS) al nivel de servicios. ^{[ 8 ] [ 9 ]} Dicho sistema tendrá interfaces separadas para enviar consultas y para enviar comandos. Como en CQS, satisfacer una solicitud de consulta solo recuperará datos y no modificará el estado del sistema (con algunas excepciones como el acceso de registro), mientras que satisfacer una solicitud de comando modificará el estado del sistema.

Muchos sistemas trasladan la segregación a los modelos de datos que utiliza el sistema. Los modelos que se utilizan para procesar consultas se denominan generalmente modelos de lectura , y los que se utilizan para procesar comandos, modelos de escritura .

Aunque su origen se suele atribuir a Greg Young en 2010, ^{[ 8 ]} todo indica que el precursor de CQRS fue Udi Dahan, quien en agosto de 2008 publicó en su blog un curso de formación que tenía como objetivo aplicar CQRS junto con SOA ^{[ 10 ]} y con más detalle en diciembre de 2009 en el artículo Clarified CQRS. ^{[ 11 ]}

• El proceso CQRS se basa en patrones y prácticas de Microsoft.
• Lista de DDD/CQRS/Event Sourcing
• Preguntas frecuentes sobre el CQRS
• CQRS: un nuevo principio arquitectónico basado en la segregación de comandos y consultas.
• Replantea tu forma de desarrollar software.
• Implementación de CQRS HelloWorld por Kapil Panchal