Expérience réelle avec l'Axon Framework

Question

Dans le cadre de mes recherches sur le CQRS en vue de son utilisation dans le cadre d'un projet, je suis tombée sur le site Web de la Commission européenne. Cadre d'Axon et je me demandais si quelqu'un avait une expérience réelle de ce produit. Pour être clair, ma question porte sur le cadre, et non sur le CQRS en tant que modèle architectural.

Mon projet utilise déjà Spring et Spring Integration, ce qui correspond parfaitement aux exigences d'Axon, mais avant d'y consacrer beaucoup de temps, j'aimerais savoir si quelqu'un a une expérience de première main. En particulier, je suis intéressé par les pièges éventuels qui ne sont pas immédiatement apparents dans la documentation.

Answer 1

Le cadre s'appuie fortement sur l'externalisation des événements, ce qui signifie que tous les changements d'état sont >écrits dans le magasin de données sous forme d'événements. "

C'est totalement faux, il ne s'appuie pas fortement sur l'approvisionnement en événements. L'une des implémentations pour le stockage de l'agrégat dans ce cadre utilise l'Event-Sourcing mais vous pouvez facilement utiliser aussi les classes fournies pour utiliser un modèle relationnel standard.

C'est tout simplement mieux avec l'event-sourcing.

Vous disposez ainsi d'une référence historique de toutes vos données. C'est bien, mais changer votre >domaine après la mise en production est une proposition très intimidante, surtout si vous avez convaincu le client de la "forte auditabilité" du système.

Je ne pense pas que ce soit beaucoup plus facile avec un modèle relationnel standard qui ne stocke que l'état actuel.

Le framework encourage la dénormalisation de vos données, au point que certains ont suggéré >d'avoir une table par vue dans l'application. Cela rend votre application extrêmement >difficile à maintenir, surtout lorsque les développeurs originaux ne sont plus là."

Cela n'est pas lié au cadre mais au modèle architectural utilisé (CQRS). Et désolé de le mentionner mais avoir un seul dénormalisateur/vue est une bonne idée car il reste un objet simple.

La maintenance est donc facile car la demande/insertion SQL est également facile. Cet argument n'est donc pas très fort. Qu'en est-il d'une vue qui utilise un modèle de 1000 tables avec des jointures internes partout et des requêtes SQL complexes ?

Là encore, CQRS est utile car, fondamentalement, les données de la vue sont simplement un SELECT * de la table qui correspond à la vue.

Si, d'une manière ou d'une autre, vous avez fait une erreur dans l'un des gestionnaires d'événements, votre seule option est de >"rejouer" le journal des événements, ce qui, selon la taille de vos données, peut prendre un temps très >long. L'outillage pour cela est cependant inexistant.

Je suis d'accord sur le fait qu'il y a actuellement un manque d'outils pour rejouer les événements et que cela peut prendre beaucoup de temps. Cependant, il est théoriquement possible de ne rejouer qu'une partie de l'événement et non tout le contenu du magasin d'événements.

Le rejeu peut avoir des effets secondaires, donc les >développeurs ont peur de le faire.

Les événements de relecture ont des effets secondaires -> c'est faux. Pour moi, les effets secondaires signifient modifier l'état du système. Dans une application CQRS basée sur des événements, l'état est stocké dans le magasin d'événements. La relecture des événements ne modifie pas le magasin d'événements. Vous pouvez avoir des effets secondaires sur le côté requête du modèle, oui. Mais vous ne vous souciez pas de savoir si vous avez fait une erreur, car vous êtes toujours en mesure de la corriger et de rejouer l'événement une nouvelle fois.

il est extrêmement facile pour les développeurs de faire des erreurs en utilisant ce cadre. s'ils ne stockent pas les >modifications des objets du domaine dans les événements, la prochaine fois que vous rejouerez vos événements, vous aurez une >surprise.

Si vous avez mal utilisé et mal compris l'architecture, le concept, etc. alors je suis d'accord avec vous. Mais peut-être que le problème n'est pas le cadre ici.

Devriez-vous stocker des deltas ? des valeurs absolues ? Si vous ne surveillez pas vos développeurs, vous risquez de vous retrouver avec les deux et vous serez dans la merde.

Je peux dire que pour chaque système, je dirais qu'il n'y a pas de lien direct avec le cadre lui-même. C'est comme dire : "Java est merdique parce que vous pouvez tout faire foirer si quelqu'un code une mauvaise implémentation des méthodes hashCode et equals."

Et pour la dernière partie de votre commentaire, j'ai déjà vu des exemples comme helloWorld avec le framework Spring. Bien sûr, c'est complètement inutile dans un exemple simple.

Faites attention dans votre commentaire à faire la différence entre le concept (CQRS + EventSourcing) et le cadre. Faites la différence s'il vous plaît.

Answer 2

Puisque vous avez déclaré vouloir utiliser CQRS pour votre projet (et que je suppose que la JVM est votre plate-forme cible), je pense que Axon Framework est un excellent choix.

J'ai construit une plate-forme de négociation assez complexe sur ce système (non, l'échantillon de négociation n'est pas complexe) et je n'ai pas vu de défauts évidents du cadre.

Puisque j'utilise EventSourcing, les dispositifs de test ont permis d'écrire très facilement des tests de style BDD "given, when, then". Cela vous permet de traiter un agrégat comme une boîte noire et de vous concentrer sur la vérification du bon ensemble d'événements qui sortent lorsque vous entrez une certaine commande.

À propos des pièges : avant de vous lancer, assurez-vous que

1. Que vous avez compris les concepts du CQRS.
2. Faites une liste (papier, tableau blanc, peu importe) de tous vos agrégats, gestionnaires de commandes, gestionnaires d'événements, sagas, commandes et événements. C'est la partie la plus difficile de la construction de votre système, déterminer ce qu'il doit faire et comment. Après cela, le manuel de référence devrait vous montrer comment connecter le tout avec Axon.

Quelques points non spécifiques à l'Axon :

La possibilité de reconstruire le magasin de vues à partir d'événements est un concept d'EventSourcing, qui n'est pas exclusif à Axon, mais j'ai trouvé assez facile de créer un service qui m'enverra tous les événements d'un type d'agrégat, d'un ID d'agrégat ou d'un certain type d'événement.

Il est formidable de pouvoir créer un nouveau composant de rapport un an après le lancement du projet et d'obtenir instantanément des rapports sur les données depuis le lancement du projet.

Answer 3

J'utilise AxonFramework depuis plus d'un an sur un projet complexe développé pour une grande banque.

Les besoins étaient exigeants, les attentes des clients étaient élevées et les délais de publication étroits.

J'ai choisi AxonFramework car, au moment du lancement du projet, il s'agissait de l'implémentation la plus complète et la mieux documentée de CQRS disponible en Java, bien conçue, facile à intégrer, à tester et à étendre.
Après plus d'un an, je pense que ces considérations sont toujours valables et actuelles.

Une autre considération a guidé mon choix : je voulais que l'engagement sur un projet aussi difficile devienne une opportunité de formation pour moi et les autres membres de l'équipe.

Nous avons commencé à développer avec la version 1.0 d'AxonFramework et sommes passés à la version 1.4 au fur et à mesure de la sortie de nouvelles versions.

L'expérience de notre équipe avec le CQRS et la mise en œuvre fournie par l'AxonFramework a été absolument positive.

Il nous a fourni une manière cohérente et uniforme de développer chaque fonctionnalité, ce qui nous a guidés et nous a permis de vous mettre à l'aise.

Sans lui, certaines fonctionnalités de l'application auraient été beaucoup plus compliquées à développer. Je fais principalement référence aux divers processus à long terme qui doivent être gérés et à la logique de compensation connexe, mais aussi aux nombreux éléments de logique d'entreprise qui ont été nécessaires, ici et là, et qui se sont bien adaptés et découplés dans l'architecture orientée événements promue par CQRS.

Notre choix a été d'être conservateur dans le modèle d'écriture, donc nous avons préféré une persistance basée sur JPA au lieu d'une persistance basée sur les événements.

Le modèle de requête est composé de vues. Nous avons essayé de faire en sorte que chaque vue contienne toutes les données requises à partir d'une seule page, en utilisant des vues intermédiaires si nécessaire.

Quoi qu'il en soit, nous avons développé le modèle d'écriture alors que nous appliquions le sourcing d'événements, de sorte que nous nous occupons de modifier l'état des agrégats exclusivement par le biais d'événements. Lorsque le client a demandé une fonction de clonage d'un agrégat très complexe, il s'agissait simplement de rejouer les événements sources (avec traduction de l'uuid) vers une toute nouvelle instance - le revers de la médaille dans ce cas a été l'upcasting des événements (mais cette fonctionnalité a été grandement améliorée dans la version 2.0 imminente).

Comme dans chaque projet, nous avons trouvé de nombreux bogues au cours du développement, principalement dans notre code, mais aussi dans des composants censés être matures et stables, comme le serveur d'application, le conteneur IoC, le cache, le moteur de flux de travail et certaines des autres bibliothèques que l'on trouve facilement dans toute grande application J2EE.

Comme tout autre produit humain, AxonFramework n'était pas non plus à l'abri des bogues, mais étonnamment, pour un projet jeune et de niche comme celui-ci, ils ont été peu nombreux, non critiques et rapidement résolus par les nouvelles versions.

Le soutien aimable et immédiat fourni par l'auteur sur la liste de diffusion est une autre caractéristique inestimable et m'a beaucoup aidé lorsque j'étais en difficulté.

L'application a été mise en production il y a un an et fait actuellement l'objet d'une maintenance et d'un développement actif de nouvelles fonctionnalités.

Le client est satisfait et en redemande.

La question est plutôt de savoir quand utiliser AxonFramework et quand utiliser CQRS. Pour y répondre, il vaut la peine de se reporter à la documentation officielle : http://www.axonframework.org/docs/1.4/introduction.html#d4e51

Dans notre cas, cela en valait définitivement la peine.

Answer 4

Le PO demande spécifiquement quels sont les pièges liés au cadre Axon plutôt qu'au CQRS. Il est donc difficile de répondre à la question, car Axon a commencé comme une mise en œuvre assez fidèle du célèbre ouvrage de Eric Evans

Le principal avantage est qu'il fait exactement ce qu'il dit sur l'étain : il gère pour vous les parties difficiles d'une conception basée sur CQRS : agrégats, sagas, event sourcing, gestionnaires de commandes, gestionnaires d'événements, cohérence BASE, etc. Lorsque vous suivez les meilleures pratiques, vous obtenez une application hautement réactive et évolutive horizontalement. Si vous l'utilisez avec l'event sourcing, vos données sont totalement auditables et, au moins en théorie, vous pouvez déterminer l'état de votre application à un moment donné. Les outils nécessaires à cette fin ne sont pas fournis ; vous devrez créer les vôtres.

Le principal développeur du cadre est très accessible et très compétent en matière d'informatique haute performance et évolutive en Java. Il a tendance à répondre à toutes les questions posées sur la liste de diffusion en quelques heures. C'est à la fois un avantage et le principal écueil : à l'heure actuelle (début 2014), l'Axon Framework dépend fortement d'une seule personne. Les autres écueils que je voudrais mentionner sont probablement plus le résultat de l'event sourcing que du CQRS ou d'Axon. (à partir de 2018, le cadre est soutenu par la société Axoniq).

Concevez votre modèle de données très soigneusement en amont. Bien qu'il soit facile de le compléter, il peut être très difficile d'apporter des modifications fondamentales à votre modèle de données. Si vous faites une erreur fondamentale dans le modèle de données, votre application risque de ne pas fonctionner correctement, voire de ne pas fonctionner du tout. Par exemple, si vous optez pour un modèle de données en forme d'arbre, avec une racine agrégée de longue durée au sommet, cet agrégat peut devenir très gros à mesure qu'il accumule de plus en plus d'événements au fil du temps, et son chargement et son stockage peuvent prendre beaucoup de temps. Je ne sais pas ce qui se passera si cela se poursuit jusqu'à ce qu'une instance de l'agrégat ne tienne plus dans la RAM, mais j'imagine que cela pourrait être mauvais. Ne le faites pas de cette façon.

Un autre écueil (lié à l'event sourcing) est qu'après un certain nombre de révisions, il peut devenir de plus en plus difficile de raisonner sur l'état d'un agrégat, car vous devez parfois garder à l'esprit non seulement ce que le code fait aujourd'hui, mais aussi ce qu'il a fait dans le passé. Cela rend définitivement la relecture (d'une partie) du magasin d'événements pour reconstruire une table de vue une tâche non triviale.

La correction des erreurs de données peut être plus difficile qu'avec une conception "traditionnelle". Plutôt qu'une simple instruction SQL, vous devrez souvent effectuer une commande pour modifier l'état de votre application. Si l'erreur dans vos données a été causée par un gestionnaire d'événements défectueux, vous pouvez généralement simplement corriger le bogue, effacer les instantanés et laisser les événements de l'agrégat être rejoués. Si votre bogue a provoqué l'application d'événements erronés, cela peut être beaucoup plus difficile à corriger. Les événements erronés resteront dans le magasin d'événements, et vous devrez peut-être en appliquer de nouveaux pour rétablir l'état correct de vos données, ou modifier le code pour ignorer ou corriger leur comportement.

Answer 5

Je fais actuellement partie d'une équipe qui travaille sur une plateforme de casino en ligne pour le lancement de notre marque. Casumo cet été. Le domaine et la plateforme sont construits à l'aide d'Axon Framework et jusqu'à présent, ils nous ont bien servis.

Nous avons gagné beaucoup de temps en n'ayant pas à mettre en place toute l'infrastructure nécessaire à la gestion des commandes, au routage des événements, à la recherche d'événements, à la prise d'images instantanées, etc. Le seul bogue que nous avons trouvé dans le framework jusqu'à présent a été corrigé dans la version 12 heures plus tard et Allard est toujours prêt à accepter des suggestions sur les nouvelles fonctionnalités et à discuter des moyens d'exploiter le framework pour répondre à vos besoins.