Multi-Tenant Arquitectura CQRS

Question

Mi equipo está empezando implementación de una aplicación totalmente nueva, con el requisito de multi-alquiler. He estado haciendo una gran cantidad de investigación sobre las pautas de sencilla escalabilidad, en especial de infraestructura basada en la nube distribuida y CQRS parece ser la palabra de moda du jour (yendo tan lejos como se llama la "grieta de Arquitectura adictos" que me parece bastante divertido ). Ventajas y desventajas a un lado, es muy difícil encontrar a alguien además de Greg joven que se ha utilizado ampliamente esta idea (o en absoluto) en aplicaciones de producción y pueden servir de guía en el mundo real para ello.

Así que aquí están mis preguntas: 1. ¿una arquitectura CQRS acomodar su aplicación típica de varios inquilinos, o es más adecuado para las aplicaciones empresariales interior mayor escala. 2. Si usted recomienda que se utiliza en esta situación, puede proporcionar alguna orientación de las trincheras en enfoques - especialmente en las cosas para hacerlo bien desde el principio, y qué aspectos deberían evolucionar de forma orgánica. 3. Si alguien ha intentado y ha resultado ser demasiado difícil o no se dio cuenta de los beneficios, o tiene argumentos fuertes en contra de ella (y recomendar que se pega a CRUD y diseño escalonado), me gustaría saber acerca de esas experiencias también.

Para referencia, la aplicación será escrito en .NET, y el extremo delantero estará inicialmente basada en Web (ASP.NET MVC), potencialmente está extendiendo a los clientes móviles y de espesor. Concurrencia, la actividad transaccional, y el volumen de datos se espera que todos a permanecer relativamente baja a lo largo de la vida útil de la aplicación (en comparación con aplicaciones financieras de alto volumen y similares). Para la infraestructura, tenemos la intención de uso de Azure.

Answer 1

He examinado el mismo punto de partida a mí mismo, desde una perspectiva exploratoria antes de embarcarse en el proyecto actual (todavía estamos esperando la financiación empresarial). En eso, mi investigación y la opinión formada a partir es que el eje de múltiples inquilinos de la arquitectura es en gran medida ortogonal a la utilización de CQRS para el diseño interno de un servicio de grano grueso. Los lugares requisito de múltiples inquilinos limitaciones generales adicionales en torno a cómo la aplicación segrega a los inquilinos de una seguridad, datos, presentación / personalización, implementación / aprovisionamiento y punto de vista de la escalabilidad. CQRS en realidad no hacer esto mejor o peor y en mi opinión todavía tiene valor para hacer frente a los retos arquitectónicos valiosos para los Servicios. Dicho esto, no todos los servicios que vagamente colaboran para proporcionar la necesidad de aplicación de seguir el patrón CQRS o bien, siempre que la arquitectura débilmente acoplado elegido no prohíbe su uso.

Answer 2

1. Multi-tenancy cambiarán un poco CQRS lado de lectura. Será necesario que las vistas de filtro y los datos relacionadas con el inquilino de retorno solamente. Y que se enfrentará a los mismos problemas que el uso de cualquier otra arquitectura.
2. Yo recomendaría CQRS ya que hará que su aplicación de una basada en tareas (no un CRUD basado). Esto significa que usted tendrá comandos recibidos desde la interfaz de usuario y van a ser más significativo que dtos. Si desea escribir su núcleo con principios DDD luego tratar de evitar anémico modelo de dominio ( http://martinfowler.com /bliki/AnemicDomainModel.html ). Acercarse a hacer esto - mover toda la lógica específica del dominio de objetos de dominio. Sus controladores de comandos deben ser muy simple (autenticar, cargar raíz agregada, traducir objeto de comando de llamada a un método, si se tiran sin excepciones - aplicar cambios). Vale la pena ver el historial de Greg clase (6 horas y media): http://cqrsinfo.com/video/ Como Michael Shimmins dicho si va a utilizar como plataforma de Azure - Vale la pena mirar a Lokad.CQRS proyecto. Lo utilicé para implementar uno de nuestros proyectos.
3. CQRS no encajará si realmente necesita la aplicación CRUD sencillo (que no se base la tarea). CQRS requieren más tiempo para entender sus principios para los recién llegados. Por otro lado se permitirá a las tareas dev separadas entre programadores de dominio de núcleo y menos experimentado Ver-> dto-> ui programadores.

Answer 3

No creo que múltiples usuarios es más duro / más fácil usando CQRS. Tiene varias ventajas si se utiliza la mensajería: puede incrustar identificación inquilino de comandos y eventos como datos de cabecera, seleccione un EventStore basado en la identificación, se combinan múltiples usuarios con múltiples instancias. 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; -)