Je viens de lire cet article , et je suis confus.
Imaginons une application Web et une application distincte agissant en tant que "travailleur", les deux partageant la même base de données .
Oh, j'ai dit "partager" ... mais de quoi cet article met-il en garde? :
Quatrièmement, le partage d'une base de données entre applications (ou services) est une mauvaise chose. Il est simplement trop tentant d'y placer un état partagé amorphe et avant de vous en rendre compte, vous aurez un monstre énormément couplé.
=> pas d'accord. Dans certains cas, des applications distinctes font toujours partie de la même unité et, par conséquent, la notion de "problème de couplage" n’a aucun sens dans ce cas.
Continuons: la webapp gère les requêtes HTTP du client et peut mettre à jour à tout moment certains agrégats (terme DDD), générant les événements de domaine correspondants.
L'objectif du travailleur serait de gérer ces événements de domaine en traitant les travaux nécessaires.
Le point est:
Comment les données d'événements doivent-elles être transmises au travailleur?
La première solution, comme le dit l'article, consiste à utiliser RabbitMQ, un excellent middleware orienté message.
Le flux de travail serait simple:
Chaque fois que le dyno Web génère un événement, il le publie via RabbitMQ, qui alimente le travailleur.
L'inconvénient serait que rien ne garantit la cohérence immédiate entre la validation de la mise à jour globale et la publication de l'événement, sans s'occuper des éventuels problèmes d'échec d'envoi ... ou de matériel; c'est un autre problème majeur.
Exemple: il serait possible qu'un événement soit publié sans succès de la mise à jour globale ... entraînant un événement représentant une fausse représentation du modèle de domaine.
Vous pourriez soutenir que le XA global (validation en deux phases) existe, mais que ce n'est pas une solution qui convient à toutes les bases de données ou middlewares.
Alors, quelle pourrait être une bonne solution pour assurer cette cohérence immédiate? :
IMO, stockant l'événement dans la base de données, dans la même transaction locale que la mise à jour globale.
Un simple planificateur asynchrone serait créé et chargé d'interroger les événements en cours non publiés de la base de données et de les envoyer à RabbitMQ, qui à son tour renseignerait l'agent de travail.
Mais pourquoi avoir besoin d'un planificateur supplémentaire à côté de Webapp et d'ailleurs: pourquoi avoir besoin de RabbitMQ dans ce cas?
Par cette solution, il apparaît logiquement que le RabbitMQ pourrait être inutile, notamment parce que la base de données est partagée.
En effet, quel que soit le cas, nous avons vu que la cohérence immédiate implique une interrogation à partir de la base de données.
Ainsi, pourquoi le travailleur ne serait-il pas directement responsable de ce scrutin?
Par conséquent, je me demande pourquoi tant d'articles sur le Web critiquent difficilement la mise en file d'attente de bases de données, tout en promouvant un middleware orienté message.
Extrait de l'article:
Simple, utilisez le bon outil pour ce travail: ce scénario nécessite un système de messagerie. Il résout tous les problèmes décrits ci-dessus; plus d'interrogation, remise efficace des messages, plus besoin d'effacer les messages terminés des files d'attente, ni d'état partagé.
Et une cohérence immédiate, ignorée?
En résumé, il semble vraiment que, quel que soit le cas, qu'il s'agisse d'une base de données partagée ou non, nous avons besoin d'une interrogation de la base de données .
Ai-je oublié certaines notions critiques?
Merci