meilleure stratégie de base de données pour le sourcing d'événements
Je souhaite configurer une petite source d'approvisionnement pour les événements ..__ J'ai lu quelques tutoriels en ligne, tout étant compris jusqu'à présent.
Le seul problème est que, dans ces différents tutoriels, il existe deux stratégies de base de données différentes, mais sans aucun commentaire sur la raison pour laquelle elles utilisent celle qu'elles utilisent.
Je tiens donc à vous demander votre avis… .. Et important, pourquoi préférez-vous la solution que vous choisissez?.
La solution est la structure de la base de données où vous créez une table pour chaque événement.
Solution est la structure de base de données dans laquelle vous créez une seule table générique et enregistrez les événements sous forme de chaîne sérialisée dans une colonne.
Dans les deux cas, je ne sais pas comment ils gèrent les changements d’événements, peut-être en créent-ils un nouveau.
Sincères amitiés
J'ai construit ma propre bibliothèque de sourcing d'événements et j'ai opté pour l'option 2 et voici pourquoi.
- Vous interrogez le flux d'événements par ID d'agrégat, pas par type d'événement.
- Reproduire les événements dans l’ordre serait difficile s’ils sont tous dans des tableaux différents
- Cela rendrait la mise à niveau un peu pénible
Il y a un argument pour dire que vous pouvez stocker des événements sur un agrégat, mais cela dépend des exigences du projet.
J'ai quelques articles sur l'utilisation des flux d'événements qui pourraient vous être utiles.
6 code odeurs avec vos événements CQRS et comment les éviter
Racine globale - Comment en créer une pour CQRS et l’approvisionnement en événements
Comment mettre à niveau les événements CQRS sans interrompre votre flux d'événements
J'espère que vous trouvez cela utile.
Solution est la structure de la base de données dans laquelle vous créez une seule table générique et enregistrez les événements sous forme de chaîne sérialisée dans une colonne.
C'est de loin la meilleure approche car la relecture d'événements est plus simple. Maintenant, mes deux sous sur le sourcing d’événements: c’est un modèle génial, mais vous devez faire attention car tout n’est pas aussi simple qu’il en a l’air. Dans un système sur lequel je travaillais, nous sauvegardions le flux d'événements par agrégat, mais nous disposions toujours d'un ensemble de tables normalisées, car nous ne pouvions tout simplement pas accepter que pour obtenir l'état le plus récent d'un objet, nous devions exécuter tous les événements. (les instantanés aident mais ne sont pas une solution parfaite). Donc, oui, l’approvisionnement en événements est un modèle fin, il vous donne une version complète de vos entités et un journal d’audit complet, et il devrait être utilisé uniquement pour cela, pas pour remplacer un ensemble de tables normalisées, mais ce ne sont que mes deux cents.
Je pense que la meilleure solution sera d'aller avec # 2 . Et même vous pouvez enregistrer votre état actuel avec l'événement associé en même temps si vous utilisez une base de données transactionnelle comme mysql.
Je n'aime pas vraiment et recommande la solution # 1 .
Si votre préoccupation pour # 1 concerne la version/mise à jour d'événement; puis déclarer une nouvelle classe pour chaque nouveau changement. Ne soyez pas trop paresseux; ou être obsédé par la réutilisation. Informez les abonnés des changements; donnez-leur la version de l'événement.
Si vos concurrents pour # 1 concernent quelque chose comme une requête/interprétation d'événements; plus tard, vous pourrez facilement transférer vos événements vers un nosqldb ou eventstore à tout moment (de la base de données originale).
Également; le motif que j'utilise pour eventsourcing lib ressemble à ceci:
public interface IUserCreated : IEventModel
{
}
public class UserCreatedV1 : IUserCreated
{
public string Email { get; set; }
public string Password { get; set; }
}
public class UserCreatedV2 : IUserCreated
{
// Fullname added to user creation. Wrt issue: OA-143
public string Email { get; set; }
public string Password { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
public class EventRecord<T> where T : IEventModel
{
public string SessionId { get; set; } // Can be set in emitter.
public string RequestId { get; set; } // Can be set in emitter.
public DateTime CreatedDate { get; set; } // Can be set in emitter.
public string EventName { get; set; } // Extract from class or interface name.
public string EventVersion { get; set; } // Extract from class name
public T EventModel { get; set; } // Can be set in emitter.
}
public interface IEventModel { }
Alors; rendre explicites les versions et la mise à niveau d'événements; à la fois dans le domaine et codebase. Implémentez la gestion des nouveaux événements dans les abonnés avant de déployer l'origine de nouveaux événements. Et; si ce n'est pas obligatoire, n'autorisez pas la consommation directe d'événements de domaine par des abonnés externes; mettre une couche d'intégration ou quelque chose comme ça.
Je souhaite que mes pensées seront utiles pour vous.
Je lis une approche sur l’approvisionnement en événements qui consiste à:
- avoir deux tables: agrégé et événement;
basez-vous sur des cas d'utilisation soit:
une. crée et enregistre sur la table agrégée, génère un ID, la version = 0 et un type d'événement et crée un événement sur la table d'événement;
b. extraire de la table agrégée, les événements par ID ou type d'événement, appliquer des analyses de rentabilisation, puis mettre à jour la table agrégée (version et type d'événement), puis créer un événement sur la table d'événements.
bien que cette approche mette à jour certains champs de la table d'agrégat, elle laisse la table d'événements comme un ajout uniquement et améliore les performances car vous disposez de la dernière version d'un agrégat dans la table d'agrégats.
J'irais avec 2 et si vous voulez vraiment avoir un moyen efficace de rechercher par type d'événement, j'ajouterais simplement un index sur cette colonne.