CQRS sagas - est-ce que je les ai bien compris?
j'essaie de comprendre sagas , et en attendant j'ai une façon spécifique de penser d'eux - mais je ne suis pas sûr si j'ai eu l'idée bonne. C'est pourquoi j'aimerais que d'autres me disent si c'est bien ou mal.
selon moi, les sagas sont une solution à la question de savoir comment modéliser les processus de longue durée . Longue signifie: Impliquant de multiples commandes, plusieurs événements et peut-être plusieurs Aggregate. Le processus n'est pas modélisé à l'intérieur d'un des agrégats participants pour éviter les dépendances entre eux.
fondamentalement, une saga n'est rien d'autre que un gestionnaire de commandes / événements qui réagit sur les commandes / événements internes et externes . Il ne contient pas sa propre logique, c'est juste une machine d'état (fini), et donc fournit des tâches telles que quand l'événement X se produit, Envoyer la commande Y .
Sagas sont conservées à l'événement en magasin ainsi que des agrégats, sont corrélées à un agrégat d'instance, et sont donc rechargé lorsque cette agrégée (ou ensemble d'agrégats) est utilisé.
c'est ça?
3 réponses
il existe différents moyens de mettre en œuvre les Sagas. Allant de manipulateurs d'événements sans état qui publient des commandes jusqu'à transporter tout l'état et étant essentiellement les agrégats du domaine eux-mêmes. Udi Dahan a écrit un article sur Sagas étant les seuls agrégats dans un (dans son cas spécifique) correctement modélisé système. Je vais vérifier et mettre à jour cette réponse.
il y a aussi le concept de sagas basées sur des documents.
votre définition de Sagas sonne juste pour moi et je les définirais aussi.
le seul changement dans votre description que je ferais est qu'une saga n'est qu'un eventhandler (pas une commande) pour un(des) événement (s) et basé sur l'événement récepteur et son état interne construit une commande et la soumet au CommandBus pour exécution.
A Normalement une Saga seulement un seul événement à partir de (StartByEvent) et plusieurs événements à la transition (TransitionByEvent) à l'état suivant et au mutiple événement à terminer par(EndByEvent).
on MSDN ils ont défini Sagas comme ProcessManager.
le terme saga est couramment utilisé dans les discussions du CQRS pour désigner un morceau de code qui coordonne et achemine les messages entre délimitée contextes et agrégats. Toutefois, aux fins de la présente Ligne directrice: préfèrent utiliser le terme de gestionnaire de processus pour désigner ce type de code artefact. Il y a deux raisons à cela: Il est bien connu, définition préexistante du terme saga ayant un sens différent de celui généralement compris en relation pour CQRS. Terme gestionnaire de processus est une meilleure description du rôle joué par cette type de code artéfact. Bien que le terme saga soit souvent utilisé dans contexte du modèle CQRS, il a une définition préexistante. Nous avons choisi pour utiliser le terme gestionnaire de processus dans ce guide pour éviter confusion avec cette définition préexistante. Le terme saga, dans rapport aux systèmes distribués, a été défini dans le document "Sagas" de Hector Garcia-Molina et Kenneth Salem. Ce document proposer un mécanisme que l'on appelle une saga comme une alternative à l'utilisation d'un transaction distribuée pour la gestion d'un long processus d'affaires. Le document reconnaît que les processus opérationnels comprennent souvent: plusieurs étapes, dont chacune comporte une transaction, et que, dans l'ensemble la cohérence peut être obtenue en regroupant ces transactions individuelles dans une transaction distribuée. Toutefois, dans les affaires en cours processus, l'utilisation de transactions distribuées peut avoir un impact sur la performance et la simultanéité du système en raison des serrures qui doit être maintenu pour la durée de la transaction distribuée.
référence: http://msdn.microsoft.com/en-us/library/jj591569.aspx