Segregación de responsabilidad de consulta y comando (CQRS) : el principio o paradigma de CQRS separa el propósito de las consultas (por ejemplo, al leer datos) y los comandos para procesar datos. La implementación de CQRS en una aplicación puede maximizar su rendimiento, escalabilidad y seguridad. La flexibilidad creada al pasar a CQRS permite que el sistema evolucione mejor con el tiempo y evita que los comandos de actualización causen conflictos de fusión a nivel de dominio. [una]
El patrón CQRS aplica programación imperativa de separación de consulta y comando ( CQS ) , utilizando objetos de consulta y comando separados para recuperar y modificar datos, respectivamente [2] [3] . CQRS fue presentado por Bertrand Meyer mientras trabajaba en el lenguaje de programación Eiffel . El principio dice que un método debe ser un comando que realiza alguna acción o una consulta que devuelve datos, pero no ambos. En otras palabras, hacer una pregunta no debería cambiar la respuesta . Más formalmente, solo un método puro (es decir , determinista y sin efectos secundarios ) puede devolver un valor . El cumplimiento estricto de este principio hace que sea imposible rastrear el número de llamadas de consulta.
CQRS encaja particularmente bien con la metodología de programación por contrato , que utiliza aserciones , incrustadas en el código fuente, para describir el estado del programa en ciertos puntos importantes. En la programación por contrato, las aserciones se refieren al diseño, no a la lógica de ejecución, por lo que ejecutarlas no debería afectar el estado del programa. CQRS es beneficioso para la programación de contratos porque se puede llamar a cualquier método de retorno de valor (cualquier consulta) en declaraciones sin preocuparse por los posibles cambios de estado del programa.
Teóricamente, esto permite conocer el estado del programa sin cambiarlo. En la práctica, CQRS permite omitir todas las comprobaciones de aserciones en un sistema en vivo para mejorar su rendimiento sin temor a que esto cambie su comportamiento. CQRS también previene que ocurran algunos Heisenbugs .
Incluso fuera de la programación por contrato, sus adherentes consideran que el uso de CQRS tiene un efecto simplista en el programa, lo que hace que acceder a su estado (a través de consultas) y cambiar su estado (a través de comandos) sea más comprensible, así como evitar el uso de goto facilita la comprensión del flujo de ejecución del programa.
CQRS se adapta bien a una metodología de programación orientada a objetos , pero también se puede aplicar fuera de OOP, ya que la separación de efectos secundarios y valores de retorno no requiere OOP, por lo que CQRS se puede aplicar de manera útil en cualquier paradigma de programación que requiere preocupación por los efectos secundarios.
CQRS puede dificultar la creación de software reentrante y de subprocesos múltiples. Este problema suele ocurrir cuando se usa un patrón no seguro para subprocesos para implementar CQRS.
Un ejemplo simple de un patrón que viola CQRS pero es útil en software de subprocesos múltiples:
int privado x ; public int incremento_y_retorno_x () { bloquear x ; // algún tipo de mecanismo de bloqueo x = x + 1 ; int x_copia = x ; desbloquear x ; // algún tipo de mecanismo de bloqueo return x_copy ; }Patrón CQRS común aplicable solo en aplicaciones de un solo subproceso:
int privado x ; valor int público () { devuelve x ; } void incremento_x () { x = x + 1 _ }Incluso en el caso de programas de un solo subproceso, a veces se puede argumentar que es mucho más conveniente tener un método que combine una solicitud y un comando. Martin Fowler da el método de pila pop() como ejemplo. [cuatro]