Multi-Tenant CQRS Architecture

Question

Mi equipo está comenzando a implementar una aplicación greenfield, con un requisito de multi-tenancy. He estado haciendo una gran cantidad de investigación sobre patrones de escalabilidad simple, especialmente en infraestructura distribuida basada en la nube, y CQRS parece ser la palabra de moda du jour (llegando incluso a llamarse "Crack for Architecture Addicts" que me parece bastante gracioso) Dejando a un lado los beneficios y las trampas, es bastante difícil encontrar a alguien además de Greg Young que haya utilizado esta idea extensamente (o en absoluto) en aplicaciones de producción y que pueda proporcionarle una guía del mundo real.

1. Estas son mis preguntas: 1. ¿Una arquitectura CQRS se adapta a su aplicación típica de varios inquilinos o es más adecuada para aplicaciones empresariales internas de mayor escala? 2. Si recomienda que se use en esta situación, ¿puede proporcionar alguna guía desde el punto de vista de las zanjas sobre los enfoques, especialmente sobre los aspectos que se deben abordar desde el principio y sobre qué aspectos se deben desarrollar orgánicamente? 3. Si alguien lo ha intentado y lo ha encontrado demasiado difícil o no se dio cuenta de los beneficios, o si tiene fuertes argumentos en contra (y recomienda adherirse a CRUD y al diseño por niveles), me gustaría saber también sobre esas experiencias.

Como referencia, la aplicación se escribirá en .NET, y la interfaz se basará inicialmente en la web (ASP.NET MVC), extendiéndose potencialmente a clientes móviles y clientes gruesos. Se espera que la concurrencia, la actividad transaccional y el volumen de datos permanezcan relativamente bajos a lo largo de la vida útil de la aplicación (en comparación con las aplicaciones financieras de gran volumen y similares). Para infraestructura, planeamos usar Azure.

Answer 1

He examinado el mismo punto de partida yo mismo, desde una perspectiva exploratoria antes de embarcarme en el proyecto real (todavía estamos esperando la financiación del negocio). En eso, mi investigación y opinión formada a partir de esto es que el eje multi-tenant de la arquitectura es en gran medida ortogonal al uso de CQRS para el diseño interno de un servicio de grano grueso.El requisito de múltiples inquilinos impone restricciones generales adicionales sobre cómo la aplicación segrega a los inquilinos desde un punto de vista de seguridad, datos, presentación/personalización, implementación/aprovisionamiento y escalabilidad. CQRS realmente no mejora o empeora esto y, en mi opinión, todavía tiene valor para abordar los valiosos desafíos arquitectónicos de los Servicios. Dicho esto, no todos los servicios que colaboran libremente para proporcionar la aplicación deben seguir el patrón CQRS tampoco, siempre que la arquitectura débilmente acoplada elegida no prohíba su uso.

Answer 2

No creo que multi-tenant sea más difícil/más fácil usando CQRS. Tiene varias ventajas si utiliza mensajes: puede incrustar la identificación del inquilino en comandos y eventos como datos del encabezado, seleccionar un almacén de eventos basado en la identificación, combinar multi-tenant con multi-instancia. Sin embargo, preguntarse si su dominio es altamente colaborativo y tienen un dominio de expertos a su disposición ... de lo contrario se termina con el comando/evento de bolo alimenticio ;-)

Answer 3

1. multiempresa cambiará un poco CQRS lado de lectura . Deberá filtrar las vistas y devolver solo datos relacionados con el inquilino. Y enfrentará los mismos problemas al usar cualquier otra arquitectura.
2. Recomendaría CQRS porque hará que su aplicación esté basada en tareas (no basada en CRUD). Significa que tendrá comandos recibidos de UI y serán más significativos que los DTO. Si desea escribir su núcleo con principios DDD, intente evitar el modelo de dominio anémico (http://martinfowler.com/bliki/AnemicDomainModel.html). Enfoque para hacer esto: mueva toda la lógica específica de dominio a objetos de dominio. Sus manejadores de comandos deberían ser muy simples (autenticar, cargar la raíz agregada, traducir el objeto de comando a la llamada de método, si no se lanzaron excepciones - aplicar cambios). Vale la pena ver el registro de clase de Greg (6 horas y media): http://cqrsinfo.com/video/ Como dijo Michael Shimmins si planea usar Azure como su plataforma, vale la pena ver el proyecto Lokad.CQRS. Lo usé para implementar uno de nuestros proyectos.
3. CQRS no funcionará si realmente necesita una aplicación CRUD simple (no basada en tareas). CQRS requiere más tiempo para entender sus principios para los recién llegados. Por otro lado, permitirá separar las tareas de desarrollo entre los programadores de núcleo de dominio y los programadores view-> dto-> ui menos experimentados.