Quels sont les inconvénients de l'utilisation de Event Sourcing et de CQRS?
L'approvisionnement en événements et CQRS sont excellents, car ils empêchent les développeurs de solutions informatiques de rester bloqués avec une base de données pré-modélisée avec laquelle ils doivent travailler pendant toute la durée de vie de l'application, à moins d'un projet de migration Big Data. CQRS et ES offrent également d’autres avantages, tels que la mise à l’échelle d’événementsstore, le journal d’audit, etc., déjà sur Internet.
Mais quels sont les inconvénients?
Voici quelques inconvénients auxquels je peux penser après avoir recherché et écrit de petites applications de démonstration.
- Complexe: Certaines personnes disent que ES est complexe. Mais je dirais qu’avoir une application complexe est préférable à un modèle de base de données complexe sur lequel vous ne pouvez exécuter que des requêtes très restreintes à l’aide d’un langage de requête (jointures multiples, index, etc.). Je veux dire que certains langages de programmation tels que Scala ont une bibliothèque de collections très riche qui est très flexible pour produire des agrégations très complexes. Il existe également Apache Spark qui facilite la recherche de collections distribuées. Mais les bases de données seront toujours limitées aux capacités de son langage d'interrogation et la distribution des bases de données est plus difficile que le code d'application distribué (Déployez simplement une autre instance sur une autre machine!).
- Utilisation élevée de l'espace disque : Le magasin d'événements peut utiliser beaucoup d'espace disque pour stocker des événements. Mais nous pouvons planifier un nettoyage toutes les quelques semaines et créer un instantané. Peut-être pouvons-nous stocker les événements historiques localement sur un disque dur externe, au cas où nous aurions besoin d’anciens événements dans le futur?
- Utilisation élevée de la mémoire : l'état de chaque objet de domaine est stocké dans la mémoire, ce qui peut augmenter l'utilisation de RAM et nous avons tous à quel point la RAM est coûteuse. GROS PROBLÈME!! parce que je suis pauvre! une solution à cela? Peut-on utiliser Sqlite au lieu de stocker l’état en mémoire? Suis-je en train de complexifier les choses en introduisant plusieurs instances Sqlite dans mon application?
- Durée de démarrage plus longue : En cas d'échec ou de mise à niveau du logiciel, le démarrage est lent en fonction du nombre d'événements. Mais pouvons-nous utiliser des instantanés pour résoudre ce problème?
- Consistance éventuelle : Problème pour certaines applications. Imaginons que Facebook utilise l’approvisionnement en événements avec CQRS pour stocker les messages et tenir compte de l’activité du système de Facebook. Si je publiais un message, je verrais mon message fb le lendemain :)
- Evénements sérialisés dans le magasin d'événements : Event stocke les événements du magasin en tant qu'objets sérialisés, ce qui signifie que nous ne pouvons pas interroger le contenu des événements dans le magasin d'événements, qui est de toute façon déconseillé. Et nous ne pourrons pas ajouter un autre attribut à l'événement à l'avenir. La solution serait de stocker les événements en tant qu’objets JSON au lieu d’événements sérialisés? Mais est-ce une bonne idée? Ou ajoutez d'autres événements pour prendre en charge le changement d'objet d'événement orignal?
Quelqu'un peut-il s'il vous plaît commenter les inconvénients que j'ai évoqués ici et me corriger si je me trompe et suggérer tout autre que j'ai peut-être manqué?
Voici mon point de vue sur ceci.
CQRS + ES simplifie énormément la tâche dans les systèmes logiciels complexes en offrant des objets de domaine riches, des modèles de données simples, un suivi de l'historique, une visibilité accrue des problèmes de simultanéité, une évolutivité et bien plus encore. Cela nécessite une approche différente de la conception des systèmes, de sorte qu'il pourrait être difficile de trouver des développeurs qualifiés. Mais CQRS simplifie la séparation des responsabilités entre les développeurs. Par exemple, un développeur débutant peut travailler uniquement avec le côté lecture sans toucher à la logique métier.
Les copies de données nécessiteront certainement plus d'espace disque. Mais le stockage est relativement bon marché ces jours-ci. L’équipe de support informatique peut être amenée à effectuer davantage de sauvegardes et à planifier la restauration du système en cas de problème. Cependant, la virtualisation des serveurs en fait un flux de travail plus simple. En outre, il est beaucoup plus facile de créer une redondance dans le système sans base de données monolithique.
Je ne considère pas l'utilisation de mémoire plus importante comme un problème. L'hydratation de l'objet métier doit être effectuée à la demande. Les objets ne doivent pas conserver de références à des événements déjà persistants. Et l'hydratation des événements ne devrait se produire que lorsque les données sont persistantes. Du côté de la lecture, vous ne disposez pas des conversions Entity -> DTO -> ViewModel qui se produisent généralement dans des systèmes multiniveaux, et vous ne disposez d'aucun type de suivi de modification d'objet comme le font habituellement les ORM. La plupart des systèmes effectuent beaucoup plus de lectures que d'écritures.
Un temps de démarrage plus long peut être un léger problème si vous utilisez plusieurs bases de données hétérogènes en raison de l'initialisation de divers contextes de données. Toutefois, si vous utilisez quelque chose de simple, comme ADO .NET, pour interagir avec le magasin d'événements et un micro-ORM pour le côté lecture, le système «démarrera à froid» plus rapidement que tout ORM complet. La chose importante ici est de ne pas trop compliquer la façon dont vous accédez aux données. C’est un problème que CQRS est censé résoudre. Et comme je l’ai déjà dit, le côté lecture devrait être modélisé pour les vues et ne pas générer de surcharge de données de remappage.
La validation en deux phases peut bien fonctionner pour les systèmes qui, selon mon expérience, ne doivent pas nécessairement être étendus. Vous devrez choisir des bases de données qui fonctionneraient bien avec le coordinateur de transactions distribuées. PostgreSQL peut par exemple bien fonctionner en lecture et en écriture. Si le système doit s’adapter à un grand nombre d’utilisateurs simultanés, il devra être conçu avec une cohérence éventuelle à l’esprit. Il existe des cas où vous avez des racines globales ou des limites de contexte qui n'utilisent pas CQRS pour éviter une éventuelle cohérence. Cela a du sens pour les parties non collaboratives du domaine.
Vous pouvez interroger des événements dans un format sérialisé, tel que JSON ou XML, si vous choisissez la bonne base de données pour le magasin d'événements. Et cela ne devrait être fait qu'à des fins d'analyse. Rien dans le système ne devrait interroger le magasin d'événements par autre chose que l'ID racine agrégée et le type d'événement. Ces données seraient indexées et vivraient en dehors de l'événement sérialisé.
Juste pour commenter le point 5. On m'a dit que Facebook utilise effectivement les ES avec une cohérence éventuelle, c'est pourquoi vous pouvez parfois voir un message disparaître et réapparaître après l'avoir posté.
En règle générale, le modèle de lecture auquel votre navigateur accède est situé «près» de vous, mais après la publication d'un message, le SPA bascule vers un modèle de lecture proche de votre modèle d'écriture. La proximité étroite entre le modèle d'écriture (événements) et le modèle de lecture vous permet de voir votre propre message.
Cependant, 15 minutes plus tard, votre SPA bascule vers le premier modèle, plus proche, en lecture. Si l'événement contenant votre message n'a pas encore été propagé à ce modèle en lecture, votre propre message disparaîtra pour réapparaître ultérieurement.
Je sais que cela fait presque trois ans que cette question a été posée, mais quand même cet article peut être utile pour quelqu'un. Les points clés sont
- Mise à l'échelle avec des instantanés
- Visibilité des données
- Changement de schéma
- Faire face à des domaines complexes
- Besoin de l'expliquer à la plupart des nouveaux membres de l'équipe
L'approvisionnement en événements et CQRS sont excellents, car ils empêchent les développeurs de solutions informatiques de rester bloqués avec une base de données pré-modélisée avec laquelle ils doivent travailler pendant toute la durée de vie de l'application, à moins d'un projet de migration Big Data.
C'est une grosse idée fausse. Les bases de données relationnelles ont été inventées exactement pour l'évolution du modèle (grâce à de simples tableaux bidimensionnels par opposition à des structures hiérarchiques prédéfinies). Avec les vues et les procédures assurant l'encapsulation de l'accès aux données, le modèle logique et physique peut évoluer de manière indépendante. C’est aussi pourquoi SQL définit DDL et DML dans le même langage. Certains SGBDR permettent également à toutes ces évolutions d'être versionnées et déployées en ligne (livraison continue) en tant que redéfinition basée sur Oracle Edition.
Les structures de données volumineuses sont prédéfinies et ne peuvent être lues qu'avec le code développé pour cette structure. Ok lorsqu'il est consommé immédiatement, mais vous aurez du mal à le lire 10 ans plus tard sans la version exacte, ni le compilateur ni l'interpréteur.