CQRS al leer con permisos para un conjunto de datos grande

Question

Estoy tratando de entender cómo el lado de lectura de CQRS puede funcionar con una gran aplicación de administración de documentos (videos/ archivos PDF/ etc.) que estamos escribiendo.

Queremos mostrar una lista de todos los documentos en los que el usuario tiene permiso de edición (es decir, muestra todos los documentos que el usuario puede editar). Podrían haber 10,000 de documentos que un usuario en particular podría editar.

En general, he leído que una sola "tabla" (estructura plana) debería ser suficiente para la mayoría de las pantallas y con permisos podría tener una tabla por rol.

¿Cómo diseñaría mi modelo de lectura para permitirme obtener rápidamente los documentos que puedo editar para un usuario específico?

Actualmente puedo ver una tabla que contiene mis documentos, otro que contiene a los usuarios y otra tabla que vincula el papel de "edición" entre el usuario y los documentos. Así que estoy haciendo uniones para obtener los datos de esta pantalla.

Además, podría haber roles para eliminar, ver, etc.

¿Es esta la forma correcta en este caso?

JD

Answer 1

Puede proporcionar una tabla plana que tenga una ID de usuario junto con la información del documento desnormalizada respectiva.

SELECT * FROM documents_editable_by_user WHERE UserId = @UserId
SELECT * FROM documents_deletable_by_user WHERE UserId = @UserId
SELECT * FROM documents_visible_for_user WHERE UserId = @UserId

Pero incluso podría crear dinámicamente una tabla/lista por usuario en su tienda de modelos de lectura. Esto se vuelve bastante fácil una vez que cambia de una tienda de lectura basada en SQL a NoSQL (si aún no lo ha hecho).

Especialmente cuando hay decenas de miles de documentos visibles o editables por un usuario, las tablas aplastadas pueden dar un impulso de rendimiento real en comparación con las uniones.

Answer 2

Cuando tuve un modelo de lectura que tomó la forma de una forma de búsqueda de filtrado (juego de palabras no previsto), utilicé la seguridad de rinoceronte como base de un servicio de autorización.

Configuré el sistema para que las tablas del servicio de autorización se impusieran a través del sistema PUB -SUB de SQL Server y el agente de SQL Server, a los clientes que mostraban parcialmente los datos desnormalizados; luego dejé Rhino.securidad Únase al modelo de autorización juntos en el modelo de lectura, por usuario.

Debido a que esencialmente nunca escribí en las tablas de autorización del modelo de lectura del modelo de lectura, obtuvimos una buena encapsulación en la base de datos y la lógica del servicio de autorización, porque la autorización solo se cambió a través de que servicio, y fue globalmente único y específico (consistente) para ese servicio. Esto significaba que nuestras GUI personalizadas para manejar los requisitos de autorización avanzados (entidades jerárquicas, grupos de usuarios, usuarios, permisos, peras por entidad) aún podrían hacer crud contra este modelo de autorización y eso se empujaría en tiempo real suave a cualquier modelo de lectura.