Quels sont les inconvénients de l'utilisation de l'Event sourcing et du CQRS?

Voici mon point de vue sur ce.

1. CQRS + ES peuvent rendre les choses beaucoup plus simples dans les systèmes logiciels complexes en ayant des objets de domaine riches, des modèles de données simples, le suivi de l'histoire, plus de visibilité dans les problèmes de concurrence, l'évolutivité et beaucoup plus. Cela nécessite une autre façon de penser les systèmes afin qu'il puisse être difficile de trouver des développeurs qualifiés. Mais le CQRS simplifie la séparation des responsabilités entre les développeurs. Par exemple, un promoteur débutant peut: travailler purement avec le côté lu sans avoir à toucher à la logique de l'entreprise.

2. les Copies de données auront besoin de plus d'espace disque à coup sûr. Mais le stockage est relativement bon marché de nos jours. Il peut être nécessaire que l'équipe de soutien informatique fasse plus de sauvegardes et planifie comment restaurer le système dans un cas où les choses vont mal. Cependant, la virtualisation des serveurs de nos jours en fait un workflow plus rationalisé. En outre, il est beaucoup plus facile de créer la redondance dans le système sans un monolithique la base de données.

3. Je ne considère pas l'utilisation de mémoire supérieure comme un problème. L'hydratation de l'objet d'affaires doit être effectuée sur demande. Les objets ne doivent pas contenir de références à des événements qui ont déjà persisté. Et l'hydratation de l'événement ne doit se produire que lorsque les données persistent. Du côté de la lecture, vous n'avez pas de conversions Entity -> DTO -> ViewModel qui se produisent habituellement dans les systèmes hiérarchisés, et vous n'auriez pas n'importe quel type de suivi de changement d'objet que les ORMs complets présentés font habituellement. La plupart des les systèmes font beaucoup plus de lectures que d'Écritures.

4. Plus de délai d'amorçage 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 données différents contextes. Cependant, 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émarrage à froid" plus rapide que n'importe quel ORM complet présenté. L'important ici est de ne pas compliquer à l'excès la façon dont vous accédez aux données. Que est en fait un problème CQRS est censé résoudre. Et comme je l'ai déjà dit, le côté lu devrait être modelé pour les vues et ne pas avoir de frais généraux de re-mapping des données.

5. Two-phase commit peut bien fonctionner pour les systèmes qui n'ont pas besoin d'échelle pour des milliers d'utilisateurs dans mon expérience. Vous devez choisir des bases de données qui fonctionneraient bien avec le coordonnateur des transactions distribuées. PostgreSQL peut bien fonctionner pour lire et écrire des modèles séparés, par exemple. Si le système les besoins à l'échelle d'un grand nombre d'utilisateurs simultanés, il devra être conçu avec cohérence éventuelle à l'esprit. Il y a des cas où vous avez des racines agrégées ou des limites de contexte qui n'utilisent pas CQRS pour éviter une cohérence éventuelle. Cela a du sens pour les parties non collaboratives du domaine.

6. vous pouvez interroger des événements dans un format sérialisé comme 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 de Analytics. Rien dans le système ne devrait interroger event store par autre chose que l'agrégat root id et le type d'événement. Que les données seraient indexées et en direct en dehors de l'événement sérialisé.