Recherche et persistance d'événements

Je lis sur la recherche d'événements et j'ai une question concernant la persistance.

Je peux toujours avoir une base de données avec toutes les entités, non? Ou les événements doivent-ils être rejoués à chaque démarrage de l'application pour obtenir la dernière version de chaque entité en mémoire? Semble comme un gaspillage sur des systèmes plus grands (comme dans une grande quantité de données)?

Le point avec la recherche d'événements est que je peux relire les événements pour remplir un magasin de données si nécessaire? (ou analyser les données)

Vous bénéficierez le plus du sourcing d'événements lorsque vous décidez de modifier également l'architecture de votre système. Aller vers une architecture de style CQRS combinée avec DDD apportera les vrais avantages d'un sourcing d'événements, du moins à mon avis.

Construire un magasin d'événements qui se comporte bien dans les grands systèmes n'est pas une tâche facile. La relecture de toutes les données peut être coûteuse, en effet, dépend beaucoup de la quantité de données à relire. Mais il existe des techniques qui pourraient vous y aider, l'une d'entre elles étant le concept d'un instantané. La relecture ne se fait qu'à partir d'un certain point. Les avantages qu'un magasin d'événements apporte à votre système sont inestimables. Ayant tout ce qui s'est passé dans votre système rejouable, toutes les données à chaque instant sont une grande chose. Pensez à l'analyse, à la reproduction des bogues, aux statistiques.

Il y a beaucoup de grands magasins d'événements, le dernier vient de sortir hier Event Store et il semble être vraiment bon.

La base de données traditionnelle peut être conservée pour la partie requête de votre système afin de créer des DTO avec les données demandées. Cette base de données peut être organisée et optimisée en fonction des besoins de requête de votre application et de vos clients.

J'ai écrit un article détaillé sur les avantages et à quoi ressemble une architecture CQRS combinée à un sourcing d'événements. Vous pouvez le vérifier sur CQRS, les événements de domaine et la révision DDD .

Avec Event Sourcing, la question principale est "quel est votre livre de référence".

Si votre livre d'enregistrement est votre flux d'événements, vous n'aurez aucun problème. Si votre livre d'archives est votre «modèle d'entité», les problèmes commenceront à se produire partout. En partie, vous pouvez dire "si je perdais mon modèle d'entité, pourrais-je le reconstruire à partir de mon flux d'événements". Si vous êtes positif sur cette question, votre journal des événements est votre registre.

Il est également important de se rappeler que la plupart des gens qui utilisent la recherche d'événements utilisent un modèle de lecture. Ce modèle est utilisé pour interroger des données. Cependant, cela ressemble plus à un modèle 1nf qu'à un modèle d'entité 3nf. Ils rejouent uniquement les événements pour récupérer les états des agrégats afin de déterminer si les écritures doivent être autorisées.

Je peux toujours avoir une base de données avec toutes les entités, non? Ou les événements doivent-ils être rejoués à chaque démarrage de l'application pour obtenir la dernière version de chaque entité en mémoire?

La réponse dépend des exigences de votre application. Je l'ai vu fonctionner dans les deux sens.

Un progiciel extrêmement réussi pour les petits cabinets comptables lit son journal CQRS à chaque démarrage. La quantité brute de données était relativement petite, donc le temps de démarrage était inférieur à une minute même sur des ordinateurs plus lents. Ils pratiquent le CQRS depuis plus d'une décennie avant que la pratique ne devienne populaire. Ils savaient qu'ils étaient sur quelque chose de bien quand ils ont réalisé qu'ils pouvaient mettre à niveau leurs données client encore et encore sans rencontrer de problèmes qu'ils voient avec leurs systèmes plus grands.

Dans les systèmes avec des volumes de données plus importants et / ou des systèmes qui s'appuient sur la fonctionnalité SGBDR pour implémenter le côté requête, vous disposez d'une base de données pour la "vue actuelle" des données provenant des événements (vous pouvez même avoir plusieurs vues de ce type). L'avantage de cette approche est qu'elle vous permet de créer le côté requête à l'aide des technologies connues.