CQRS: cómo modelar un sistema de ejecución de escenarios

Question

Recientemente comencé a investigar CQRS y DDD para un proyecto de campo verde que estoy a punto de comenzar. Estudié una gran cantidad de material de Udi Dahan, Greg Young, Mark Nijhof y otros. Estos fueron realmente muy útiles y creo que tengo una buena comprensión de los conceptos. Pero todavía hay ciertas preguntas en mi mente sobre cómo puedo aplicarlas a mi propio dominio.

Mi sistema básicamente será un motor de reglas complejo, en el que las reglas dictarán el precio final de ciertos productos. Los administradores definirán las definiciones y reglas del producto en el sistema. Las reglas las diseñarán los administradores utilizando un conjunto predefinido de propiedades que pueden tener valores de un conjunto predefinido, como 'Propósito de compra' (revender, alquilar) o valores de forma libre, como Edad.

Cada producto tendrá un precio base, y las reglas básicamente se sumarán/eliminarán del precio base si se aplican.

Una regla de ejemplo muy simple podría ser:

del producto X, SI (Compra Propósito = revender y edad> 25) Añadir 25 $ al precio base.

Así que hay dos tipos de usuarios que usan el sistema, los administradores, que definen los productos, las reglas y los precios base; y otros usuarios que consultan los precios en función de un escenario en el que ingresan a través de una interfaz de usuario what-if.

Mi confusión aquí es esta: ejecutar un escenario no cambia el estado del dominio en absoluto, ningún otro sistema externo/persona está interesado en el resultado de la ejecución del escenario sino el propio usuario en ejecución - devuelve el resultado de un cálculo de precio después de ejecutar las reglas aplicables para el escenario dado. Por ejemplo, el usuario puede seleccionar Producto X y consultar los precios para un escenario dado, como (Purchase Purpose = Reventa y Age = 40). De nuevo, dado que esta operación no cambia el estado del dominio, creo que es una consulta. Pero, hay un motor de reglas operando en el escenario para calcular el precio final, que supongo se puede categorizar como la lógica de dominio que se está ejecutando. Entonces, ¿a dónde pertenece esta lógica? ¿Es esta una consulta que solo funciona con el modelo de lectura, o ejecuta un escenario, un comando que debe ejecutarse en el modelo de dominio? De nuevo, parece que la capa de dominio es el lugar adecuado para estas reglas, pero ¿cómo paso el resultado de la ejecución del escenario al usuario? (Se siente como una consulta que piensa de esta manera). O tal vez, CQRS no es la solución correcta para este problema en particular?

Answer 1

Tuve este problema exacto en mi propio dominio (e-scheduling 4 healthcare). Básicamente, el sistema se configura utilizando un modelo de dominio (lado de escritura). Esto definiría reglas, productos y precios base en su dominio. ¿Qué sale del dominio? Eventos, cambios de estado, cosas que sucedieron junto con por qué sucedió. Ahora lo que hice fue consumir estos eventos en un contexto delimitado diferente, en mi caso un motor de búsqueda complejo que encuentra espacios libres en los horarios de los médicos, quirófanos y equipos costosos. Esta podría ser una ruta que también podría tomar, consumir el producto, el precio base y los eventos relacionados con las reglas y almacenarlos de tal manera que el motor de reglas, al estar sobre esos datos, pueda manejar las solicitudes de escenarios con la misma eficiencia que los usuarios. posible. Lo más probable es que descubra que el modelo para almacenar cambios (dominio) difiere del modelo optimizado para consultar esos escenarios hipotéticos (motor de reglas). Es probable que su dominio tenga reglas como "no se puede especificar el mismo producto dos veces" o "esta regla nunca coincidirá (edad & edad> 25)". El dominio solo se refiere a permitir cambios de estado válidos. Esto no es una preocupación del motor de reglas. Tendrá la tentación de reutilizar conceptos/clases en su motor de reglas que estén definidos en el dominio. Resiste ese impulso.Pregunta si realmente sirven para el mismo propósito. Modelarlo dos veces para un propósito diferente no es sucio o una violación de DRY.

Answer 2

CQRS no dice nada acerca de que no debería haber lógica de dominio en la parte de consulta de la aplicación. Si es posible y práctico, está bien tener almacenes de consultas desnormalizados separados para cada aspecto o incluso consulta de su aplicación, pero por supuesto no es necesario.

En resumen, una consulta es una consulta, sin importar cuán compleja sea la tarea de encontrar su respuesta.