Supposons que nous voulons implémenter un petit sous-système de sécurité pour une application financière qui avertit les utilisateurs par e-mail si un modèle étrange est détecté. Pour cet exemple, le modèle consistera en trois transactions comme celles illustrées. Le sous-système de sécurité peut lire les événements du système principal à partir d'une file d'attente.
Ce que j'aimerais obtenir, c'est une alerte qui est une conséquence directe des événements qui se produisent dans le système, sans représentation intermédiaire qui modélise l'état actuel du modèle.
- Surveillance activée
- Transaction traitée
- Transaction traitée
- Transaction traitée
- Alerte déclenchée (id: 123)
- E-mail d'alerte envoyé (pour id: 123)
- Transaction traitée
Dans cette optique, je pensais que le sourcing d'événements pouvait très bien s'appliquer ici, même si j'ai une question sans réponse claire. L'alerte déclenchée dans l'exemple a un effet secondaire clair, un e-mail doit être envoyé, une circonstance qui ne devrait se produire qu'une seule fois. Par conséquent, cela ne devrait pas se produire lors de la relecture de tous les événements d'un agrégat.
Dans une certaine mesure, je vois l'e-mail qui doit être envoyé similaire aux matérialisations générées par le côté requête que j'ai vu tant de fois dans la littérature sur le sourcing CQRS / Event, avec une différence pas si subtile cependant.
Dans cette littérature, le côté requête est construit à partir de gestionnaires d'événements qui peuvent générer une matérialisation de l'état à un point donné en relisant tous les événements. Dans ce cas, cependant, cela ne peut pas être accompli exactement comme ça pour les raisons expliquées précédemment. L'idée que chaque état est transitoire ne s'applique pas si bien ici . Nous devons enregistrer le fait qu'une alerte a été envoyée quelque part.
Une solution simple pour moi serait d'avoir une table ou une structure différente où vous gardez des enregistrements des alertes qui ont été déclenchées précédemment. Comme nous avons une pièce d'identité, nous pourrions vérifier si une alerte avec la même pièce d'identité a été émise auparavant. La possession de ces informations rendrait le SendAlertCommand idempotent. Plusieurs commandes peuvent être émises, mais l'effet secondaire ne se produira qu'une seule fois.
Même en ayant cette solution à l'esprit, je ne sais pas si c'est un indice qu'il y a quelque chose de mal avec cette architecture pour ce problème.
- Mon approche est-elle correcte?
- Y a-t-il un endroit où je peux trouver plus d'informations à ce sujet?
Il est étrange que je n'ai pas pu trouver plus d'informations à ce sujet. J'ai peut-être utilisé une mauvaise formulation.
Merci beaucoup!