C'est facile pour les projections qui s'abonnent à tous les événements du flux, il vous suffit de conserver la version du dernier événement appliqué sur votre modèle de lecture. Mais que faites-vous lorsque la projection est composée de plusieurs flux? Conservez-vous la version de chaque flux qui participe à la projection. Mais qu'en est-il des lacunes, si vous ne vous abonnez pas à tous les événements? Tout au plus, vous pouvez affirmer que la version est supérieure à la dernière. Comment les autres gèrent-ils cela? Répondez-vous à chaque événement et augmentez-vous la (les) version (s)?
3 Réponses :
Pour chaque flux individuel, vous gardez les choses en ordre en les récupérant dans un magasin de données qui connaît le bon ordre. Une façon de penser à cela est que votre requête sur le magasin de données, et vous obtenez un Message de document retour.
Il peut être utile de consulter la discussion de Greg Young sur les Polyglot Data .
Quant à la synchronisation des événements dans plusieurs flux; une chose que vous devez reconnaître est que les événements dans différents flux sont intrinsèquement simultanés.
Vous pouvez obtenir une coordination lâche entre différents flux si vous avez des données survenant avant encodées dans vos messages. "L'événement B s'est produit en réponse à l'événement A, donc A s'est produit avant B". Cela vous donne une commande partielle.
Si vous avez vraiment besoin d'un ordre total de tout partout, vous devrez rechercher des modèles comme Horloges Lamport .
En plus de traiter les messages dans le bon ordre, vous rencontrez également le problème de reprendre une projection après son redémarrage - comment vous assurez-vous de partir du bon endroit lorsque vous redémarrez?
L'option la plus simple est d'utiliser un magasin d'événements ou un courtier de messages qui garantit à la fois l'ordre et fournit une sorte de champ de position de flux global (tel qu'un numéro d'événement global ou un horodatage ordonné avec un composant non ambigu comme le type d'horodatage de MongoDB). Les magasins d'événements dans lesquels vous extrayez les événements directement du magasin (comme eventstore.org ou ceux créés en interne sur une base de données) ont tendance à le garantir. En outre, certains courtiers de messages comme Apache Kafka garantissent la commande (encore une fois, c'est basé sur l'extraction). Vous souhaitez une livraison commandée au moins une fois, idéalement.
Cette approche limite l'évolutivité en écriture (lecture à l'échelle fine, en utilisant des réplicas en lecture) - vous pouvez partager vos flux sur plusieurs instances de magasin d'événements de différentes manières, puis vous devez suivre la position par partition, ce qui ajoute une certaine complexité .
Si vous ne disposez pas de ces garanties de commande, de livraison et de positionnement, votre vie est beaucoup plus difficile et il peut être difficile de rendre le système complètement fiable. Vous pouvez:
Pour l'EventStore, je suggère d'utiliser le flux $ all comme flux par défaut pour tout abonnement de modèle de lecture.
J'ai utilisé le flux de catégorie qui produit essentiellement l'instantané d'un type d'entité donné, mais j'ai arrêté de le faire car les modèles de lecture ont un objectif différent.
Il peut ne pas être souhaitable d'utiliser le flux $ all car il peut également obtenir des événements, qui ne sont pas des événements de domaine. Les événements d'intégration pourraient être un exemple. Dans ce cas, l'ajout d'attributs aux contrats d'événement ou aux métadonnées peut aider à créer une projection interne (JS) qui créera un flux tout spécial pour les événements de domaine, ou toute catégorie d'événements à cet égard. , où vous pouvez vous abonner. Vous pouvez également utiliser une condition négative, par exemple, filtrer tous les événements système et ceux dont le nom de flux d'origine commence par Integration .