Le projet GitHub CQRS.NET a quelques exemples concrets de la façon dont vous pourriez faire des EventStores dans quelques technologies différentes. Au moment de la rédaction de cet article, il existe une implémentation en SQL utilisant Linq2SQL et un schéma SQL qui va avec, il y en a un pour MongoDB , un pour DocumentDB (CosmosDB si vous êtes dans Azure) et un utilisant EventStore (comme mentionné ci-dessus). Il y a plus dans Azure comme le stockage de table et le stockage Blob qui est très similaire au stockage de fichiers plats.
Je suppose que le point principal ici est qu'ils sont tous conformes au même principal / contrat. Ils stockent tous les informations dans un seul endroit / conteneur / table, ils utilisent des métadonnées pour identifier un événement à partir d'un autre et `` juste '' stocker l'événement entier tel qu'il était - dans certains cas sérialisé, dans des technologies de support, pour ainsi dire. Donc, selon que vous choisissez une base de données de documents, une base de données relationnelle ou même un fichier plat, il existe plusieurs façons d'atteindre la même intention d'un magasin d'événements (c'est utile si vous changez d'avis à tout moment et que vous avez besoin de migrer ou de prendre en charge plusieurs technologies de stockage).
En tant que développeur du projet, je peux partager quelques idées sur certains des choix que nous avons faits.
Premièrement, nous avons trouvé (même avec des UUID / GUID uniques au lieu d'entiers) pour de nombreuses raisons, les ID séquentiels se produisent pour des raisons stratégiques, ainsi le simple fait d'avoir un ID n'était pas assez unique pour une clé, nous avons donc fusionné notre colonne de clé ID principale avec les données / type d'objet pour créer ce qui devrait être une clé vraiment unique (au sens de votre application). Je sais que certaines personnes disent que vous n'avez pas besoin de le stocker, mais cela dépendra du fait que vous soyez un nouveau site ou que vous deviez coexister avec des systèmes existants.
Nous nous sommes contentés d'un seul conteneur / table / collection pour des raisons de maintenabilité, mais nous avons joué avec une table séparée par entité / objet. Nous avons trouvé dans la pratique que cela signifiait que l'application avait besoin d'autorisations "CREATE" (ce qui n'est généralement pas une bonne idée ... en général, il y a toujours des exceptions / exclusions) ou à chaque fois qu'une nouvelle entité / objet est apparue ou a été déployée, une nouvelle des conteneurs / tables / collections de stockage doivent être réalisés. Nous avons constaté que cela était extrêmement lent pour le développement local et problématique pour les déploiements de production. Vous ne pouvez pas, mais c'était notre expérience du monde réel.
Une autre chose à retenir est que demander à l'action X de se produire peut entraîner de nombreux événements différents, connaissant ainsi tous les événements générés par une commande / un événement / ce qui est utile. Ils peuvent également concerner différents types d'objets. Par exemple, pousser «acheter» dans un panier peut déclencher des événements de compte et d'entreposage. Une application consommatrice peut vouloir savoir tout cela, nous avons donc ajouté un CorrelationId. Cela signifiait qu'un consommateur pouvait demander tous les événements soulevés à la suite de sa demande. Vous verrez cela dans le schéma .
Plus précisément avec SQL, nous avons constaté que les performances devenaient vraiment un goulot d'étranglement si les index et les partitions n'étaient pas correctement utilisés. N'oubliez pas que les événements doivent être diffusés dans l'ordre inverse si vous utilisez des instantanés. Nous avons essayé quelques index différents et avons constaté qu'en pratique, certains index supplémentaires étaient nécessaires pour déboguer les applications du monde réel en production. Encore une fois, vous verrez cela dans le schéma .
D'autres métadonnées en production ont été utiles lors des enquêtes basées sur la production, les horodatages nous ont donné un aperçu de l'ordre dans lequel les événements ont été persistés par rapport à leur déclenchement. Cela nous a donné une certaine assistance sur un système particulièrement axé sur les événements qui a soulevé de grandes quantités d'événements, nous donnant des informations sur les performances de choses comme les réseaux et la distribution des systèmes sur le réseau.