Étant donné le service A (CMS) qui contrôle un modèle (produit, supposons que les seuls champs qu'il possède sont l'identifiant, le titre, le prix) et les services B (expédition) et C (e-mails) qui doivent afficher le modèle donné, quelle devrait être l'approche synchroniser les informations de modèle données sur ces services dans une approche de sourcing d'événements? Supposons que le catalogue de produits change rarement (mais change) et qu'il existe des administrateurs qui peuvent accéder très souvent aux données des envois et des e-mails (les fonctionnalités sont par exemple: B: display titles of products the order contained
et C:) display content of email about shipping that is going to be sent
. Chacun des services a sa propre base de données.
Solution 1
Envoyer toutes les informations requises sur le produit dans l'événement - cela signifie la structure suivante pour order_placed
:
{
order_id: [guid],
product: {
id: [guid],
title: 'Foo',
price: 1000
}
}
Sur le service B et C, les informations sur les produits sont stockées dans l' product
attribut JSON de la orders
table
Ainsi, pour afficher les informations nécessaires, seules les données extraites de l'événement sont utilisées.
Problèmes : en fonction des autres informations qui doivent être présentées en B et C, la quantité de données en cas d'événement peut augmenter. B et C peuvent ne pas nécessiter les mêmes informations sur le produit, mais l'événement devra contenir les deux (sauf si nous séparons les événements en deux). Si des données données ne sont pas présentes dans un événement donné, le code ne peut pas l'utiliser - si nous ajoutons une option de couleur à un produit donné, pour les commandes existantes en B et C, le produit donné sera incolore à moins que nous ne mettions à jour les événements et les réexécutions .
Solution 2
Envoyer uniquement le guide du produit dans l'événement - cela signifie la structure suivante pour order_placed
:
{
order_id: [guid],
product_id: [guid]
}
Sur les services, les informations sur les produits B et C sont stockées dans l' product_id
attribut de la orders
table
Les informations sur les produits sont récupérées par les services B et C lorsque cela est requis en effectuant un appel d'API au A/product/[guid]
point de terminaison
Problèmes : cela rend B et C dépendants de A (à tout moment). Si le schéma du produit change sur A, des changements doivent être effectués sur tous les services qui en dépendent (soudainement)
Solution 3
Envoyer uniquement le guide du produit dans l'événement - cela signifie la structure suivante pour order_placed:
{
order_id: [guid],
product_id: [guid]
}
Sur les services B et C, les informations sur les produits sont stockées dans un products
tableau; il y a toujours product_id
sur la orders
table, mais il y a réplication des products
données entre A, B et C; B et C peuvent contenir des informations sur le produit différentes de celles de A
Les informations sur les produits sont prédéfinies lorsque les services B et C sont créés et sont mises à jour chaque fois que les informations sur les produits changent en effectuant un appel au A/product
point de terminaison (qui affiche les informations requises de tous les produits) ou en effectuant un accès DB direct à A et en copiant les informations nécessaires sur les produits requises pour des données données. un service.
Problèmes : cela rend B et C dépendants de A (lors de l'ensemencement). Si le schéma du produit change sur A, des changements doivent être effectués sur tous les services qui en dépendent (lors de l'amorçage)
D'après ma compréhension, l'approche correcte serait d'aller avec la solution 1, et de mettre à jour l'historique des événements selon une certaine logique (si le catalogue de produits n'a pas changé et que nous voulons ajouter une couleur à afficher, nous pouvons mettre à jour l'historique en toute sécurité pour obtenir l'état actuel des produits et remplir les données manquantes dans les événements) ou répondre à la non-existence de données données (si le catalogue de produits a changé et que nous voulons ajouter de la couleur à afficher, nous ne pouvons pas être sûrs si à ce moment-là dans le passé produit donné avait une couleur ou non - nous pouvons supposer que tous les produits du catalogue précédent étaient noirs et répondre en mettant à jour les événements ou le code)
updating event history
je veux dire: parcourez tous les événements, en les copiant d'un flux (v1) dans un autre flux (v2) pour maintenir un schéma d'événement cohérent.
display image at the point when purchase was made
) ou ne peut pas (représentant l' intention de display current image as it within catalog
)
updating event history
- Dans la recherche d'événements, l'historique des événements est votre source de vérité et ne doit jamais être modifié, mais seulement aller de l'avant. Si les événements changent, vous pouvez utiliser la version des événements ou des solutions similaires, mais lors de la relecture de vos événements jusqu'à un moment précis, l'état des données doit être tel qu'il était à ce moment-là.