Architecture CQRS multi-locataire

Question

Mon équipe commence la mise en œuvre d'une nouvelle application, avec une exigence de multi-location. J'ai fait beaucoup de recherches sur les modèles pour une évolutivité simple, en particulier sur l'infrastructure distribuée basée sur le cloud, et CQRS semble être le mot à la mode du jour (allant jusqu'à être appelé "Crack for Architecture Addicts"). Avantages et inconvénients mis à part, il est assez difficile de trouver quelqu'un d'autre que Greg Young qui a largement utilisé cette idée (ou pas du tout) dans les applications de production et qui peut fournir des conseils concrets pour cela. Voici donc mes questions: 1. Une architecture CQRS s'adapte-t-elle à votre application multi-locataire typique ou est-elle mieux adaptée aux applications d'entreprise internes à plus grande échelle? 2. Si vous recommandez qu'il soit utilisé dans cette situation, pouvez-vous fournir des conseils sur les approches des tranchées, en particulier sur les choses à faire dès le début, et sur les aspects qui devraient évoluer organiquement. 3. Si quelqu'un a essayé et trouvé trop difficile ou non réalisé les avantages, ou a de solides arguments contre (et recommande de coller à CRUD et à plusieurs niveaux), j'aimerais aussi connaître ces expériences.

Pour référence, l'application sera écrite en .NET et la partie frontale sera initialement basée sur le Web (ASP.NET MVC), potentiellement étendue aux clients mobiles et aux clients lourds. La simultanéité, l'activité transactionnelle et le volume de données devraient rester relativement faibles tout au long de la durée de vie de l'application (par rapport aux applications financières à volume élevé et autres). Pour l'infrastructure, nous prévoyons d'utiliser Azure.

Answer 1

J'ai examiné le même point de départ moi-même, d'un point de vue exploratoire avant de me lancer dans le projet actuel (nous attendons toujours le financement de l'entreprise). En cela, ma recherche et mon opinion à partir de là est que l'axe multi-locataires de l'architecture est largement orthogonal à l'utilisation de CQRS pour la conception interne d'un service à gros grains.L'exigence de multi-locataires impose des contraintes supplémentaires supplémentaires sur la manière dont l'application sépare les locataires d'un point de vue sécurité, données, présentation/personnalisation, déploiement/approvisionnement et évolutivité. Le CQRS ne rend pas vraiment cela meilleur ou pire et, à mon avis, il est toujours utile d'aborder les défis architecturaux de valeur pour les Services. Cela dit, tous les services qui collaborent librement pour fournir l'application ne doivent pas non plus suivre le modèle CQRS, à condition que l'architecture faiblement couplée choisie n'interdise pas son utilisation.

Answer 2

Je ne pense pas que le multi-locataire est plus difficile/plus facile d'utiliser CQRS. Vous avez divers avantages si vous utilisez la messagerie: vous pouvez intégrer l'identification du locataire dans les commandes et les événements en tant que données d'en-tête, sélectionner un magasin d'événements en fonction de l'identification, combiner multi-locataires avec plusieurs instances. Pourtant, demandez-vous si votre domaine est hautement collaboratif et un expert de domaine à votre disposition ... sinon vous vous retrouvez avec commande/événement ruminage ;-)

Answer 3

1. Multi-location va changer un peu CQRS côté lecture . Vous devrez filtrer les vues et renvoyer uniquement les données relatives aux locataires. Et vous rencontrerez les mêmes problèmes en utilisant n'importe quelle autre architecture.
2. Je recommanderais CQRS parce qu'il rendra votre application basée sur les tâches (pas une base CRUD). Cela signifie que vous aurez des commandes reçues de l'interface utilisateur et qu'elles auront plus de sens que les DTO. Si vous voulez écrire votre noyau avec les principes DDD, essayez d'éviter le modèle de domaine anémique (http://martinfowler.com/bliki/AnemicDomainModel.html). Approche pour le faire - déplacez toute la logique spécifique au domaine vers les objets du domaine. Vos gestionnaires de commandes doivent être très simples (s'authentifier, charger la racine de l'agrégat, traduire l'objet de commande en appel de méthode, si aucune exception n'a été levée - appliquer les modifications). Il est intéressant de regarder l'enregistrement de classe de Greg (6 heures et demie): http://cqrsinfo.com/video/ Comme l'a dit Michael Shimmins, si vous envisagez d'utiliser Azure comme plate-forme - cela vaut la peine de regarder le projet Lokad.CQRS. Je l'ai utilisé pour mettre en œuvre un de nos projets.
3. CQRS ne convient pas si vous avez vraiment besoin d'une application CRUD simple (pas basée sur une tâche). Les CQRS ont besoin de plus de temps pour comprendre ses principes pour les nouveaux arrivants. D'un autre côté, cela permettra de séparer les tâches de développement entre les programmeurs de domaine et les programmeurs de visualisation moins expérimentés.