Passer des données relationnelles aux événements

Guide pour passer des données relationnelles aux événements

• Dans l'Église de l'event sourcing, les données métier sont préservées sous forme d'événements sans être perdues.
• Les événements représentent des faits qui se sont produits et sont stockés après chaque opération.
• Un flux d'événements est la liste de tous les événements enregistrés ; il est immuable et les erreurs passées peuvent être corrigées en ajoutant de nouveaux événements.

1. Repérer les colonnes d'état

• Les valeurs des colonnes d'état peuvent refléter les étapes du cycle de vie des données.
• Par exemple, une commande peut être initiée, expédiée et payée.
• Ces états peuvent être transformés en événements comme Order Initiated, Order Shipped et Order Paid.

2. Vérifier les colonnes de date

• Les colonnes de date peuvent fournir des informations sur les événements importants d'un processus.
• ShipmentDate, DeliveryDate, OrderPlacementDate, etc. révèlent le vocabulaire métier et peuvent aider à introduire de nouveaux événements.

3. Analyser la sélectivité des colonnes

• Les colonnes nullable peuvent être renseignées plus tard ou rester optionnelles.
• Les colonnes obligatoires doivent être fournies dès le premier événement Order Initiated.

4. Rechercher les tables avec le plus de relations 1 à N

• En event sourcing, les données sont regroupées autour des processus métier pour favoriser un traitement efficace.
• Les tables qui ont de nombreuses relations 1 à N peuvent être de bonnes candidates pour devenir des types de flux.

5. Introduire des événements explicites

• Lors de la migration de données relationnelles vers des événements, les événements nouvellement découverts ne doivent pas être réutilisés pendant l'import ; il faut fournir explicitement un événement Order Imported.

6. Expérimenter et valider

• Il faut essayer un prototype dans un environnement sûr, comparer les résultats aux attentes, avancer sans précipitation et itérer.

L'avis de GN⁺

• Le point le plus important de cet article est l'importance d'une nouvelle approche qui préserve les données métier lors du passage d'une base de données relationnelle à l'event sourcing.
• Cet article est intéressant parce qu'il propose une manière de mieux comprendre et exploiter le cycle de vie des données, en sortant des approches traditionnelles de gestion des données.
• L'event sourcing peut aider non seulement sur le plan technique, mais aussi à construire une compréhension commune entre les équipes métier et techniques.

[GN⁺]

Avis Hacker News

• Recommandation d’utiliser PostgreSQL et des outils de reporting FOSS

  • Si l’application utilise déjà PostgreSQL, il est recommandé d’y stocker les données d’événements et d’utiliser des outils de reporting FOSS comme Apache Superset ou Metabase.
  • PostgreSQL est utilisé jusqu’à ce que les données atteignent environ 2 To, puis il faut décider s’il est vraiment nécessaire de garder 2 To de données en ligne ou si seuls des résumés quotidiens/horaires sont nécessaires.
  • Dans le cas d’un client, plus de 10 To de données et 1 500 événements par seconde sont traités ; les données détaillées sont conservées en ligne pendant 2 jours, puis le reste est agrégé et déplacé vers S3 pour être interrogeable via Athena SQL.
  • AWS RDS Multi-AZ est utilisé pour prendre en charge le basculement automatique, et un seul ingénieur maintient l’ensemble avec moins de 5 heures de travail par mois.
  • PostgreSQL fournit un système unique pour stocker, apprendre, administrer et faire évoluer les données au même endroit.
  • Même le personnel non technique peut facilement créer des graphiques dans des systèmes comme Metabase ou Preset.
  • PostgreSQL progresse chaque année et, si nécessaire, une montée en charge supplémentaire est possible via des systèmes compatibles PostgreSQL comme Aurora, TimescaleDB ou CitusDB.

• Quand utiliser une architecture orientée événements à bon escient

  • Lorsqu’un client effectue une action précise et attend une réponse, il ne s’agit pas d’un modèle orienté événements mais d’un schéma requête/réponse.
  • L’orienté événements désigne les cas qui se produisent de manière non anticipée. Par exemple, pousser du code sur GitHub déclenche un build.

• Retour d’expérience sceptique sur l’event sourcing

  • Une équipe a envisagé l’event sourcing, mais a finalement décidé de ne pas l’utiliser, faute d’avantages clairs et en raison du risque lié à l’essai de quelque chose de nouveau.
  • Il n’y a pas de regret d’avoir manqué une occasion d’apprentissage, et le fait de ne pas se jeter dans un problème complexe sans nécessité est vu positivement.

• Utilité de la modélisation par événements de domaine

  • La modélisation par événements de domaine est utile pour communiquer avec les experts métier du domaine que l’on cherche à résoudre.
  • Lorsqu’il faut implémenter un système fournissant une piste d’audit sur de longues périodes pour des machines à états, il vaut mieux utiliser des outils comme Temporal.io/durable functions.
  • Ces outils utilisent l’event sourcing en interne et imposent d’écrire le code en tenant compte de la déduplication et de l’idempotence.

• Question sur l’implémentation de l’event sourcing

  • Il manque des explications sur la manière de reconstruire efficacement l’état actuel à partir d’un flux d’événements et sur la façon de modéliser ce flux d’événements dans la base de données.

• Bottom-up vs top-down, sur mesure vs générique

  • L’approche top-down part du domaine métier puis fait correspondre l’implémentation aux technologies, outils et fournisseurs disponibles.
  • L’approche bottom-up part des technologies, outils et fournisseurs disponibles puis assemble une solution fonctionnelle.
  • L’approche sur mesure inclut DDD, CQRS/ES, Sagas, TBUI, GraphQL, les types de données algébriques, etc.
  • L’approche générique inclut RDBMS, CRUD, REST, transactions ACID, CDC, interfaces d’administration génériques, no-code/low-code, types limités/génériques, etc.

• Soutien et critique de l’architecture orientée événements

  • Il y a un soutien envers l’architecture orientée événements, mais l’article ne parvient pas à exprimer clairement son argument.
  • En se concentrant sur la différence entre les relations de données et les comportements métier, il devient plus clair pourquoi il faut s’éloigner d’un stockage relationnel opérationnel.

• Event sourcing et nécessité des relations

  • Malgré les nombreux avantages de l’event sourcing, les relations restent nécessaires.
  • Si toutes les relations sont seulement implicites dans le code de la couche applicative, ce n’est pas acceptable.
  • Il faut un moyen d’interroger ces relations ou de maintenir à jour des vues relationnelles.

• Soutien aux données relationnelles

  • La décision a été prise d’éviter la complexité et de rester fidèle aux données relationnelles traditionnelles.

• Nouvelle prise de conscience du design orienté événements

  • Le design orienté événements a été découvert récemment, et en réfléchissant à la structure de données optimale dans un monde dominé par l’IA, une conclusion similaire a été atteinte.
  • Si le design orienté événements permet de gérer la complexité et d’exploiter réellement les données, il pourrait avoir de la valeur.
  • Il est prévu qu’au cours des prochaines années, à mesure que l’IA pourra interroger des connaissances sur tous les événements métier, le design orienté événements se généralise.