Get best of the week

Pourquoi Event Sourcing est l'anti-modèle pour l'interaction des microservices

Rebonjour. En mars, OTUS lance le prochain volet du cours d' architecte logiciel . En prévision du début du cours, nous avons préparé une traduction de matériel utile pour vous.



Récemment, les architectures événementielles (architectures événementielles) et, en particulier, Event Sourcing (la génération d'événements) se sont généralisées. Ceci est motivé par le désir de créer des systèmes modulaires durables et évolutifs. Dans ce contexte, le terme «microservices» est souvent utilisé. À mon avis, les microservices ne sont qu'un des moyens de mettre en œuvre un « contexte borné ». Il est très important de définir correctement les limites des modules, et la conception stratégique , décrite par Eric Evans dans Domain Driven Design, y contribue . Il vous aide à identifier / détecter les modules, les limites («contexte restreint») et à décrire comment ces contextes sont liés les uns aux autres (carte de contexte, ContextMap).

Les événements de domaine comme base d'une langue unique


Bien que cela ne soit pas explicitement indiqué dans le livre d'Eric Evans, les événements de domaine contribuent très bien aux concepts DDD. Des pratiques telles que l' événement Storming Alberto Brandolini déplacent le centre d'intérêt des événements du niveau technique au niveau organisationnel et commercial. Ici, nous ne parlons pas d'événements d'interface utilisateur, tels que cliquer sur un bouton (ButtonClickedEvent), mais d'événements de domaine qui font partie du domaine. Ils sont discutés et compris par des experts dans le domaine. Ces événements sont les principaux concepts et contribuent à former une langue unique (langue omniprésente ), avec laquelle tous les participants (experts en la matière, développeurs, etc.) seront d'accord.

Événements de domaine utilisés pour communiquer entre les contextes


Les événements de domaine peuvent être utilisés pour interagir entre des contextes restreints. Supposons que nous ayons une boutique en ligne avec trois contextes: commande (livraison), livraison (livraison), facture (compte).

Considérez l'événement «Commande acceptée» dans le contexte de la commande. Le contexte Facture ainsi que le contexte Livraison sont intéressés à surveiller cet événement, car cet événement déclenche certains processus internes dans ces contextes.

Le mythe de la faible connectivité


L'utilisation d'événements de domaine permet de développer des modules à couplage lâche. Les modules individuels peuvent ne pas être disponibles temporairement. Mais pour un événement de domaine, il n'est absolument pas important qu'ils soient disponibles ou non, car l'événement décrit uniquement ce qui s'est passé dans le passé. D'autres modules décident quand traiter l'événement. Vous obtenez un système flexible par défaut.

Outre le découplage temporel, les événements de domaine vous offrent un autre avantage: le contexte de commande n'a pas besoin de savoir que le contexte des factures et des livraisons écoute ses événements. En fait, il n'a même pas besoin de savoir que ces contextes existent.

C'est très bien, mais la difficulté réside dans le choix des données à stocker lors de l'événement?

La réponse simple: Event Sourcing!


Les événements sont utiles, alors pourquoi ne pas les utiliser au maximum. C'est l'idée principale de l' événement sourcing . Vous stockez l'état de l'unité non pas en mettant à jour ses données (CRUD), mais en utilisant un flux d'événements.
Outre le fait que vous pouvez jouer à des événements et obtenir un statut, il existe une autre fonctionnalité d'Event Sourcing: vous obtenez gratuitement un journal d'audit complet. Par conséquent, lorsqu'un tel journal est requis, lors du choix d'une stratégie de stockage, assurez-vous de faire attention à Event Sourcing.

Le sourçage d'événements n'est qu'un niveau de stockage


Il peut vous sembler étrange que je sois immédiatement passé des événements de domaine au stockage, car, évidemment, ce sont des concepts de différents niveaux.

... et voici mon point: Event Sourcing est une solution locale utilisée dans un seul contexte limité! Les événements Event Sourcing ne doivent pas être retirés au monde extérieur! D'autres contextes limités n'ont pas besoin de savoir comment les données des uns et des autres sont stockées. Par conséquent, peu importe si un certain contexte utilise le sourçage d'événements

Si vous utilisez Event Sourcing à l'échelle mondiale, vous divulguez votre niveau de stockage.

La méthode de stockage des données devient votre API publique. Chaque fois que vous apportez des modifications au niveau de stockage, vous devrez faire face à un changement dans l'API publique.

Je suis sûr que tout le monde conviendra que c'est mauvais lorsque divers contextes limités partagent des données dans une base de données (relationnelle) en raison de la connectivité qui en résulte. Mais en quoi est-ce différent de Event Sourcing? Rien. Peu importe si vous utilisez des événements partagés ou des tables partagées dans la base de données. Dans les deux cas, vous partagez les détails de stockage.

Il y a une sortie


Je soutiens toujours que les événements de domaine sont idéaux pour interagir entre des contextes limités, mais ces événements ne devraient pas être liés aux événements qui sont utilisés pour le sourçage d'événements.

La solution proposée est très simple: quelle que soit l'approche que vous utilisez pour stocker les données (CRUD ou Event Sourcing), vous publiez les événements de domaine dans le magasin d'événements global. Ces événements représentent l'API publique de votre contexte. Lorsque vous utilisez Event Sourcing, vous stockez des événements Event Sourcing dans votre magasin local, accessible uniquement pour ce contexte limité.

liberté de choix


Le fait d'avoir des événements de domaine séparés dans l'API publique vous permet de les modéliser de manière flexible. Vous n'êtes pas limité à un modèle prédéfini par Event Sourcing.

Il existe deux options pour travailler avec des «événements du monde réel»: un service de protocole ouvert et une langue publique (service hôte ouvert, langue publiée) ou un client / fournisseur.

Service avec un protocole ouvert et une langue publique (Open Host Service, Published Language)


Un seul événement de domaine est publié qui contient toutes les données dont d'autres contextes limités peuvent avoir besoin. Dans la terminologie DDD, cela peut être appelé un service hôte ouvert et un langage publié.



Le début de l'événement du monde réel "Order Accepted" conduit à la publication d'un événement de domaine OrderAccepted . La charge utile de cet événement contient toutes les données de commande dont d'autres contextes restreints pourraient avoir besoin ... alors j'espère que les contextes de facturation et de livraison trouveront toutes les informations dont ils ont besoin.

Fournisseur client


Pour chaque consommateur, des événements distincts sont publiés. Il est nécessaire de coordonner les modèles de chaque événement avec un seul consommateur, il n'est pas nécessaire de déterminer un modèle commun partagé. DDD appelle cette relation Client / Fournisseur.



La survenue d'événements réels «Commande acceptée» conduit à la publication d'événements individuels pour chacun des consommateurs: InvoiceOrderAcceptedet DeliveryOrderAccepted. Chaque événement de domaine contient uniquement les données nécessaires au contexte du destinataire.

Je ne veux pas discuter maintenant des avantages et des inconvénients de ces approches. Je veux simplement attirer l'attention sur le fait que vous pouvez choisir le nombre d'événements de domaine et les données qu'ils stockent.

C'est un avantage que vous ne devez pas sous-estimer, car vous pouvez décider comment développer l'API de votre contexte limité sans être lié aux événements Event Sourcing.

Conclusion


L'exposition de pièces de stockage est un anti-motif bien connu. En parlant de stockage, nous pensons principalement aux tables de base de données, mais nous avons vu que les événements utilisés pour Event Sourcing ne sont qu'une autre façon de stocker des données. Par conséquent, les distribuer est également un anti-modèle.


Traduction: "un bon développeur comme un loup-garou a peur des balles d'argent."

Event Sourcing est une approche puissante si elle est utilisée correctement (localement). À première vue, il semble que pour les architectures orientées événement, c'est une solution miracle, mais si vous regardez de près, vous pouvez voir que cette approche peut conduire à une connexion solide ... ce que vous ne voulez bien sûr pas.

Références


En plus de mon expérience personnelle, j'ai reçu beaucoup d'inspiration de divers articles et conférences. Je voudrais mentionner la présentation d'Eberhard Wolff «Architecture et implémentations basées sur les événements avec Kafka et Atom» (architecture et implémentation d'événements utilisant Kafka et Atom). En particulier sur Event Sourcing et ce que sont les événements , ce qui est très pertinent dans le contexte de ce post. L'exemple de la boutique en ligne a également été inspiré par cet exposé.

Si vous souhaitez plus d'informations, vous pouvez vous référer à ces ressources:


: « : ».

More articles:


All Articles