Quand utiliser le modèle de conception CQRS?
Mon équipe et moi avons discuté de l'utilisation du modèle de conception CQRS (Command Query Responsibility Segregation) et nous essayons toujours d'évaluer les avantages et les inconvénients de son utilisation. Selon: http://martinfowler.com/bliki/CQRS.html
nous n'avons pas encore vu suffisamment d'utilisations du CQRS dans le domaine pour être confiants que nous comprenons ses avantages et inconvénients
Alors, qu'en pensez-vous, quand un problème nécessite-t-il l'utilisation du CQRS?
Le CQRS n'est pas un modèle qui englobe l'ensemble de l'application.
Il s'agit d'un concept qui s'appuie sur la conception pilotée par domaine (DDD). Et un concept stratégique important de DDD est le soi-disant Contexte borné.
Dans une application typique, il existe plusieurs contextes bornés, dont chacun peut être implémenté de la manière qui lui convient. Par exemple
- Gestion des utilisateurs -> CRUD
- Facturation -> CRUD
- Gestion des polices d'assurance (le domaine principal) -> CQRS
- ...
Cela ne répond probablement pas à votre question, mais cela pourrait donner un peu plus d'informations sur le sujet. Pour être honnête, je ne pense pas qu'on puisse y répondre du tout sans prendre en compte les spécificités d'un projet, et même alors il y a rarement quelque chose comme une meilleure pratique définie .
Les critiques du CQRL peuvent dire que le CQRS est compliqué et cela pourrait être vrai.
Bien sûr, cela ajoute des frais généraux en développant une application CRUD simple dans le style CQRS, donc je n'envisagerais d'utiliser CQRS que dans les cas suivants:
- Grande équipe - Vous pouvez facilement répartir les tâches de développement entre les personnes si vous avez choisi l'architecture CQRS. Vos meilleurs employés peuvent travailler sur la logique du domaine, laissant les choses habituelles aux développeurs moins qualifiés.
- Logique métier difficile - Le CQRS vous oblige à éviter de mélanger la logique du domaine et les opérations d'infrastructure.
- L'évolutivité est importante - Avec CQRS, vous pouvez obtenir d'excellentes performances de lecture et d'écriture, la gestion des commandes peut être étendue sur plusieurs nœuds et comme les requêtes sont des opérations en lecture seule, elles peuvent être optimisées pour effectuer des opérations de lecture rapide.
Lorsque vous avez un domaine commercial complexe ou difficile et:
- avec sourcing événementiel; vous voulez une belle façon de tester la logique
- avec sourcing événementiel; vous voulez prouver vos comportements par des tests et des raisonnements
- vous avez plusieurs clients ou consommateurs de votre service de domaine (pas seulement un seul serveur Web)
OU vous avez des utilisateurs qui doivent agir sur des données communes:
- et vous souhaitez formaliser les concepts de fusion de données de votre domaine
- ou vous souhaitez appliquer la logique de fusion des événements
OU vous avez des exigences d'évolutivité:
- vous appliquez le modèle en tant que modèle de dénormalisation qui supprime les goulots d'étranglement
- vous souhaitez mettre à l'échelle horizontalement et non verticalement
OU vous avez des problèmes de performances (autre côté de l'évolutivité):
- par exemple. vous devez migrer votre architecture vers une architecture événementielle - le CQRS en tant que modèle est un bon tremplin.
OU vous avez une équipe physiquement disjointe:
- par exemple. certaines parties de votre équipe se trouvent dans un autre pays
- ou il est difficile d'obtenir une communication en face à face, donc vous voulez dissocier les modèles de lecture du côté écriture des choses (sagas, domaine, CRUD)
Ce n'est pas le CQRS qui est trop compliqué, ce sont les ordinateurs qui le sont.
Quand utiliser le modèle de conception CQRS?
Le modèle d'architecture CQRS peut être utilisé lorsqu'il est difficile d'interroger à partir des référentiels toutes les données que les utilisateurs doivent visualiser. Cela est particulièrement vrai lorsque la conception UX crée des vues de données qui traversent plusieurs types d'agrégats et instances. Plus votre domaine est sophistiqué, plus cela a tendance à être vrai.
Lorsqu'il est inapproprié de faire des compromis sur la conception UX, l'utilisation de CQRS tente d'atténuer les problèmes associés à d'autres solutions, telles que:
- obliger les clients à utiliser plusieurs référentiels pour récupérer toutes les instances agrégées; ou
- la conception de viseurs spécialisés sur divers référentiels pour recueillir des données disjointes à l'aide d'une seule requête.
Pour résumer: utilisez CQRS lorsqu'il est difficile d'interroger les données des référentiels que les utilisateurs doivent consulter, ce qui a tendance à se produire plus votre domaine est sophistiqué.
De mon point de vue, cela ajoute deux avantages majeurs (parmi beaucoup d'autres).
- Capacité de mise à l'échelle extrême
- Très utile pour les équipes distibuées.
Voici les raisons d'utiliser CQRS:
- Évolutivité (la lecture dépasse l'écriture, les exigences de mise à l'échelle diffèrent pour chacune et peuvent être mieux traitées)
- Flexibilité (modèles de lecture/écriture séparés)
- Complexité réduite (déplacement de la complexité dans des préoccupations distinctes)
- Concentrez-vous sur le domaine/l'entreprise
- Facilite la conception d'interfaces utilisateur intuitives basées sur les tâches
Dans le scénario du monde réel, CQRS peut être utile lorsque vous avez un client de service frontal/Web qui a besoin de beaucoup de données de plusieurs domaines et que la récupération de ces données de la base de données prend beaucoup de temps.
Dans ce cas, vous pourriez envisager de créer un modèle de lecture distinct qui sera plus rapide à développer et pourrait avoir un temps d'exécution plus rapide.