Qui et comment doit gérer les événements de relecture?

Par souci de simplicité, supposons un processus sans état - notre service n'essaie pas de conserver des copies des éléments en mémoire, mais recharge plutôt les agrégats si nécessaire.

Le service reçoit AddItemToCardCommand: {card: 123, ...} . Nous n'avons pas l'état actuel de la card: 123 en mémoire, nous devons donc le créer. Nous faisons cela en chargeant l'état de la carte: 123 à partir de notre magasin durable. Parce que nous avons choisi d'utiliser le stockage événementiel, «l'état» que nous lisons dans le magasin durable est une représentation de l'historique des événements précédemment écrits par le service.

Les historiques d'événements contiennent toutes les informations dont vous avez besoin de vous souvenir, mais pas nécessairement sous une «forme» pratique - les listes d'ajout uniquement sont une excellente structure de données pour les écritures, mais pas nécessairement pour les lectures.

Cela signifie souvent que nous «rejouerons» les événements pour créer un objet en mémoire que nous pourrons ensuite utiliser pour répondre aux questions sur les événements que nous écrirons ensuite.

Le même modèle est utilisé pour répondre à des requêtes simples: nous chargeons l'historique des événements à partir du magasin, transformons l'historique des événements en une forme plus pratique, puis utilisons cette forme pour calculer la réponse.

Dans les cas où la latence des requêtes est plus importante que la rapidité, nous pouvons concevoir notre gestionnaire de requêtes pour lire les formes pratiques à partir d'un cache, plutôt que d'essayer de les calculer à chaque fois; un thread d'arrière-plan fonctionnant simultanément serait chargé de se réveiller périodiquement pour calculer de nouveaux contenus pour le cache.

L'utilisation d'un processus asynchrone pour extraire les mises à jour d'un flux d'événements est un modèle courant; Greg Young discute de certains des avantages de cette approche dans son exposé sur Polyglot Data .

Dans un scénario d'événement idéal, vous n'auriez pas une structure d'agrégation déjà construite disponible dans votre base de données. Vous arrivez à plusieurs reprises à la structure de données finale en parcourant tous les événements stockés jusqu'à présent.

Permettez-moi d'illustrer avec un pseudocode d'ajout d'articles au panier, puis de récupérer les données du panier.

cart = Cart(id=ID1)

# Fetch contents of Cart with id ID1
for each event in ID1 cart's events:
    if event is ItemAddedToCart:
        cart.add_item(event.data)
    else if event is ItemRemovedFromCart:
        cart.remove_item(event.data)

return cart

Ce qui peut aider, c'est de ne pas considérer la commande comme un changement d'état mais plutôt l ' événement comme un changement d'état. En fait, je ne vois pas très bien comment procéder autrement. Le gestionnaire de commandes de votre agrégat appliquerait les invariants et, si tout va bien, créerait immédiatement l'événement et appellerait une méthode qui l'appliquerait ( [Apply | On | Do] MyEvent ). Le fait que vous ayez un événement après coup ne signifie pas nécessairement que d’autres parties de votre système le géreraient. Il est cependant requis pour la recherche d'événements. Une fois que vous avez un événement, vous pouvez très certainement le transmettre à d'autres parties de votre système via, par exemple, la publication sur un bus de service.

Lorsque vous rejouez vos événements, vous appelez les mêmes méthodes que les commandes appelaient pour muter. l'état de votre agrégat:

public MyEvent MyCommand(string data)
{
    if (string.IsNullOrWhiteSpace(data))
    {
        throw new ArgumentException($"Argument '{nameof(data)}' may not be empty.");
    }

    return On(new MyEvent
    {
        Data = data
    });
}

private MyEvent On(MyEvent myEvent)
{
    // change the relevant state
    someState = myEvent.Data;

    return myEvent;
}

Votre infrastructure de recherche d'événements appellerait On (MyEvent) pour MyEvent lors de la relecture. Puisque vous avez un événement , cela signifie qu'il était une transition d'état valide et peut simplement être appliqué; Sinon, quelque chose s'est mal passé dans le traitement de votre commande initial et vous avez probablement un bogue.

Tous les événements d'un magasin d'événements seraient dans l'ordre chronologique pour un agrégat. En plus de cela, les événements doivent avoir un numéro de séquence global pour faciliter le traitement de la projection.

Vous pouvez avoir une projection générique qui accepte tout / tous les événements, puis publie l'événement sur un bus de service pour l'intégration du système. Vous pouvez également placer ce fardeau sur un client du magasin d'événements pour qu'il garde une trace de la position elle-même, puis lise les événements sur le magasin lui-même. Vous pouvez les combiner et demander au client de s'abonner aux événements du bus de service, mais assurez-vous qu'il les exécute dans le même ordre en gardant une trace de la position (numéro de séquence global) elle-même et en la mettant à jour au fur et à mesure que les événements sont traités.

p>