Comment commencer à utiliser CQRS avec le framework Axon sur une base de données existante

Question

Nous avons une application web existante utilisant une base de données graphique que nous voulons passer à une architecture en utilisant cqrs avec le framework Axon.

Je me demande s'il existe des pratiques exemplaires concernant les données qui se trouvent déjà dans notre base de données de production. Nous devons remplir une base de données d'index (elasticsearch) que je voudrais garder à jour en utilisant des écouteurs d'événements. Cet index doit être initialisé avec les données déjà en production, mais n'a aucun événement associé avec celles-ci. Ma première pensée est juste de générer un tas de commandes de création à partir de la base de données existante, de sorte que le remplissage de l'index est fait uniquement avec des événements. Cela prend probablement un certain temps en première manche, mais nous sommes probablement d'accord avec ça.

Cela vous semble-t-il une bonne idée? D'autres pensées à ce sujet?

Answer 1

La migration d'une application à CQRS est pas une tâche facile, et certainement pas quelque chose à faire en une seule étape. Cependant, si l'application est correctement configurée, il est certainement possible de se déplacer lentement vers (plus) CQRS. Comme votre défi semble être d'ajouter un modèle de vue supplémentaire (celui d'ElasticSearch), mon conseil serait de commencer par publier des événements. Dans Axon Framework, cela signifierait définir un bus d'événement et lui envoyer des messages. Sur le "côté élastique", définissez un certain nombre de gestionnaires d'événements qui écoutent ces événements et y apportent les mises à jour nécessaires. Vous pouvez choisir de mettre les données nécessaires dans les événements, ou simplement utiliser les événements comme un «déclencheur» pour interroger l'état actuel de votre application. Une prochaine étape pourrait consister à utiliser des gestionnaires de commandes, un bus de commande et des messages de commande pour les modifications demandées par vos composants frontaux (ou d'intégration). Une fois que vous en avez, vous pouvez commencer à penser à retirer ces composants du gestionnaire de commandes dans un composant séparé (en utilisant des événements pour mettre à jour les composants de requête qui restent après la séparation).

Avant chaque étape, tenez compte de la quantité de travail et des avantages réels qu'ils vous procurent. Il pourrait, par exemple, ne pas valoir la peine de retirer les composants de gestion de commande. Envoyer des événements à partir d'un «monolithe» peut déjà vous donner assez de flexibilité pour construire des composants séparés autour d'elle.

Answer 2

Juste pour partager une certaine expérience:

• J'ai commencé avec les Handlers commande de passerelle et de commande pour envoyer et gérer des commandes dans mes contrôleurs Spring MVC et ordonnanceurs de tâches. Les événements semblent également intéressants, mais je n'ai pas encore trouvé le moyen d'intégrer des événements (sans approvisionnement d'événements) à la couche de persistance de données de printemps ou de persistance de mybatis existante.

apprécieront s'il y a un exemple sur cet aspect :-)