Quand utiliser le modèle de conception CQRS?

Mon équipe et moi avons discuté de l’utilisation du modèle de conception CQRS (Séparation de la responsabilité de la commande) et nous essayons toujours d’évaluer le pour et le contre de son utilisation. Selon: http://martinfowler.com/bliki/CQRS.html

nous n’avons pas encore vu assez d’utilisations du CQRS sur le terrain pour être sûrs de comprendre ses avantages et ses inconvénients

Alors, vous pensez quoi, quand un problème appelle-t-il l’utilisation de CQRS?

    CQRS n’est pas un modèle qui englobe toute l’application.

    C’est un concept qui s’appuie sur la conception pilotée par le domaine (DDD). Et un concept stratégique important de DDD est le soi-disant Contexte limité .

    Dans une application typique, il existe plusieurs contextes bornés, chacun pouvant être implémenté comme il se doit. Par exemple

    • Gestion des utilisateurs -> CRUD
    • Facturation -> CRUD
    • Gestion des fonts d’assurance (le domaine principal) -> CQRS

    Cela ne répond probablement pas à votre question mais cela pourrait donner un peu plus de détails sur le sujet. Pour être honnête, je ne pense pas qu’il soit possible d’y répondre du tout sans tenir compte des spécificités d’un projet, et même alors, il y a rarement quelque chose qui ressemble à une meilleure pratique .

    Les critiques de CQRL pourraient bien dire que le CQRS est compliqué et que cela pourrait être vrai.

    Bien sûr, cela ajoute du temps à la création d’une application CRUD simple dans le style CQRS, alors j’envisagerais d’utiliser CQRS uniquement dans les cas suivants:

    1. 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 collaborateurs peuvent travailler sur la logique de domaine en laissant des tâches de routine à des développeurs moins qualifiés.
    2. Logique métier difficile – CQRS vous oblige à éviter de mélanger la logique de domaine et les opérations d’infrastructure.
    3. L’évolutivité est importante – Avec CQRS, vous pouvez obtenir d’excellentes performances de lecture et d’écriture, le traitement des commandes peut être étendu sur plusieurs noeuds et, lorsque les requêtes sont en lecture seule, elles peuvent être optimisées pour effectuer des opérations de lecture rapides.

    Lorsque vous avez un domaine d’activité complexe ou difficile et:

    • avec recherche d’événements; vous voulez un bon moyen de tester la logique
    • avec recherche d’événements; vous voulez prouver vos comportements en testant et en raisonnant
    • vous avez plusieurs clients, ou consommateurs, de votre service de domaine (pas seulement un serveur Web unique)

    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 une logique pour la fusion d’événements

    OU vous avez des exigences d’évolutivité:

    • vous appliquez le motif comme un motif de dénormalisation qui supprime les goulots d’étranglement
    • vous voulez mettre à l’échelle horizontalement et non verticalement

    OU vous avez des problèmes de performance (autre côté de l’évolutivité):

    • Par exemple, vous devez migrer votre architecture vers une architecture orientée événement – CQRS en tant que modèle est un bon tremplin.

    OU vous avez une équipe physiquement disjointe:

    • par exemple des parties de votre équipe sont dans un autre pays
    • ou il est difficile d’avoir une communication en face à face, donc vous voulez découpler les modèles de lecture du côté écriture des choses (sagas, domaine, CRUD)

    Ce n’est pas trop compliqué, ce sont des ordinateurs.

    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 afficher. Cela est particulièrement vrai lorsque la conception UX crée des vues de données qui recoupent plusieurs types et instances d’agrégats. Plus votre domaine est sophistiqué, plus cela a tendance à être vrai.

    Lorsqu’il est impossible de compromettre la conception UX, l’utilisation de CQRS tente d’atténuer les problèmes associés aux autres solutions, telles que:

    • obliger les clients à utiliser plusieurs référentiels pour récupérer toutes les instances d’agrégat; ou
    • la conception de détecteurs spécialisés sur divers référentiels pour rassembler des données disjointes en utilisant une seule requête.

    En résumé: utilisez CQRS lorsqu’il est difficile d’interroger les référentiels que les utilisateurs de données doivent consulter, ce qui se produit généralement plus votre domaine est sophistiqué.

    De mon sharepoint vue, cela ajoute deux avantages majeurs (parmi beaucoup d’autres).

    1. Capacité de mise à l’échelle extrême
    2. Très utile quand il s’agit d’équipes dissortingbuées.

    Dans le scénario réel, CQRS peut être utile lorsque vous avez un client de service frontal / Web nécessitant beaucoup de données provenant de plusieurs domaines et que l’extraction de ces données de la firebase database prend beaucoup de temps.

    Dans ce cas, vous pourriez envisager de créer un modèle de lecture distinct, qui serait plus rapide à développer et pourrait avoir un temps d’exécution plus rapide.

    Voici les raisons d’utiliser CQRS:

    1. Évolutivité (la lecture dépasse l’écriture, de même les exigences de mise à l’échelle diffèrent et peuvent être améliorées)
    2. Flexibilité (modèles séparés de lecture / écriture)
    3. Complexité réduite (transformer la complexité en problèmes distincts)
    4. Concentré sur le domaine / entreprise
    5. Facilite la conception d’interfaces utilisateur intuitives basées sur des tâches