cqrs

Xendor

Xendor es un marco de .NET Core que se puede utilizar para crear un diseño simple y limpio al hacer cumplir la responsabilidad única y la separación de las preocupaciones. Sus características avanzadas son ideales para el diseño impulsado por el dominio (DDD), la segragación de responsabilidad de consultas de comandos (CQRS) y el abastecimiento de eventos. Xendor también tiene integraciones de RabbitMQ.

¿Qué es CQRS?

La segregación de responsabilidad de la cuidia de comandos es un patrón que nos dice que separemos las operaciones que mutan datos de las que lo consultan. Se deriva de la separación de consultas de comando (CQS) CQS establece que solo puede haber dos tipos de métodos en una clase: los que mutan el estado y devuelven vacío y los que devuelven el estado pero no lo cambian.

CQRS es un patrón en el que aplica? ¿El interior? de su servicio/aplicación y puede aplicarlo solo a la parte de su servicio.

Que no es CQRS

No es consistencia eventual

No es eventing

No es mensajes

No tiene modelos separados para leer y escribir

Tampoco está usando el abastecimiento de eventos.

CQRS Pros & Contres

Pros:

• mejor rendimiento y escalabilidad de su sistema.
• Mejor manejo de acceso concurrente.
• mejor escalabilidad del equipo.
• Modelo de dominio menos complejo y modelo de consulta simple.

Contras:

• Los modelos de lectura y escritura deben mantenerse sincronizados.
• Costos de mantenimiento y administración Si elige dos motores diferentes para la lectura y para el lado de la escritura.
• La consistencia eventual no siempre está permitida.

¿Qué es el abastecimiento de eventos?

En lugar de almacenar solo el estado actual de los datos en un dominio, use un almacén exclusivo para registrar la serie completa de acciones tomadas en esos datos. La tienda actúa como el sistema de registro y puede usarse para materializar los objetos de dominio. Esto puede simplificar las tareas en dominios complejos, evitando la necesidad de sincronizar el modelo de datos y el dominio comercial, al tiempo que mejora el rendimiento, la escalabilidad y la capacidad de respuesta. También puede proporcionar consistencia para los datos transaccionales y mantener los senderos de auditoría y el historial completos que pueden permitir acciones compensadoras.

¿En qué sistemas vale la pena usar el abastecimiento de eventos?

• Su sistema tiene muchos comportamientos que no son una ráfaga ordinaria.
• Recrear estados históricos de objetos es muy importante
• Los usuarios comerciales ven las ventajas de tener un historial completo para estadísticas, aprendizaje automático u otros fines.
• Los eventos describen mejor su dominio (por ejemplo, una aplicación para rastrear las actividades de un vehículo de asistencia).

Events Surcing Pros & Contras

Pros:

• El modelo de agregar solamente es excelente para el rendimiento, la escalabilidad
• Sin estallidos
• Los eventos (hechos) son bien entendidos por el experto en negocios, algunos dominios se obtienen inherentemente de eventos: contabilidad, atención médica, comercio
• Pista de auditoría gratis
• Podemos obtener el estado del objeto en cualquier momento
• Fácil de probar y depurar
• modelo de datos desacoplado del modelo de dominio
• Sin desajuste de impedancia (modelo de objetos versus modelo de datos)
• flexibilidad? Se pueden construir muchos modelos de dominio diferentes a partir del mismo flujo de eventos.
• Podemos usar este modelo con eventos de inversión, eventos retroactivos
• ¿No más Orms? Gracias al hecho de que nuestro objeto está construido a partir de eventos, no tenemos que reflejarlo en una base de datos relacional.

Contras:

• No es una forma natural para que los desarrolladores manejen el estado y construyan agregados, lleva tiempo acostumbrarse a
• Consultar más allá de un agregado es un poco más difícil (debe construir proyecciones para cada tipo de consulta que desee agregar al sistema),
• Los cambios en el esquema de eventos son mucho más difíciles que en el caso del modelo relacional (falta de herramientas de migración de esquema estándar)
• Debe considerar el manejo de versiones desde el principio.

Abastecimiento de eventos - Proyecciones

La proyección es un concepto importante al tiempo de construir sistemas centrados en eventos. Al mismo tiempo, es extremadamente simple.

La proyección se trata de derivar el estado actual del flujo de eventos.

Por ejemplo, considere una situación, donde un servidor publica un flujo de eventos para todos los suscriptores. Estos eventos están relacionados con los registros de los usuarios y parecen:

Usuarios de usuarios

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "name" : " Alejandro " ,
 "lastName" : " Moline "
}

UserVerifiMail

{
 "userId" : 55 ,
 "email" : " [email protected] "
}

De usuario

{
 "userId" : 55 ,
 "lastName" : " Molines "
}

Podemos adjuntar un suscriptor para transmitir estos eventos para proyectar esta transmisión en un modelo de lectura persistente, utilizado para atender los detalles del usuario en una interfaz de usuario web. El modelo de lectura final podría parecer:

{
 "userId" : 55 ,
 "username" : " alemol " ,
 "email" : " [email protected] " ,
 "name" : " Alejandro " ,
 "lastName" : " Molines "
}

CQRS con abastecimiento de eventos (CQRS-ES)

¡Dale una estrella!

Si lo desea o está utilizando este proyecto, déle una estrella. ¡Gracias!

Encontré un problema o tengo una solicitud de cambio

Siéntase libre de crear un problema en GitHub. ¡Contribuciones, las solicitudes de extracción son más que bienvenidas!

Xendor es Copyright © 2019 Alejandro Molines y otros contribuyentes bajo la licencia MIT.