Je suis sur le point de créer une conception basée sur le domaine autour de la file d'attente RabbitMQ, et je suis totalement nouveau dans ce domaine. Je voudrais savoir s'il existe des lignes directrices pour identifier les différentes files d'attente compte tenu des contextes délimités.
Des choses comme une file d'attente par contexte limité, ou une file d'attente par type de ressource dans des contextes limités.
Et comme les files d'attente traversent normalement différents contextes bornés, cela rend les choses plus compliquées.
Un conseil?
3 Réponses :
Vous avez besoin d'une file d'attente par type de consommateur.
Considérons un type de consommateur C1 qui gère les événements de type E1 et E2. Une file d'attente Q1 est requise dans laquelle tous les événements de type E1 et E2 sont acheminés. Si un autre type de consommateur C2 gère les événements de type E3 et E4, une file d'attente Q2 est requise dans laquelle tous les événements de type E3 et E4 sont acheminés.
Est-il bon d'avoir un acteur consommant de plus d'une file d'attente, cela signifie-t-il que les files d'attente doivent être fusionnées d'une manière ou d'une autre, ou que l'acteur en fait trop et doit être divisé en deux ou plusieurs acteurs?
Un gars a fait une réponse intéressante puis elle a été supprimée. Il a dit que les files d'attente ne faisaient pas partie du DDD sauf que je concevais un nouveau Rabbit, et qu'elles faisaient simplement partie de l'infrastructure de communication. Je suis entièrement d'accord. Ma question ne porte pas sur DDD lui-même, mais comme il l'a dit, c'est plutôt sur la façon d'identifier ou de choisir les bonnes files d'attente de rabbitMQ pour transporter les messages dans mon DDD. Une entité de domaine doit consommer des événements d'une manière ou d'une autre.
"Considérons un type de consommateur C1 qui gère les événements de type E1 et E2. Une file d'attente Q1 est requise dans" n'est pas tout à fait vrai. Un consommateur peut consommer plusieurs files d'attente, E1 et E2 peuvent se trouver dans des files d'attente différentes.
Il y a 2 "préoccupations" (couches) majeures que j'ai tendance à utiliser.
Pour tout système logiciel de taille raisonnable, j'utiliserais une file d'attente par contexte borné qui ne concerne que les commandes du BC en question. Le point de terminaison gérant les messages serait nommé selon les lignes de System.BoundedContextA.Server et ce point de terminaison ne gérerait que les commandes de BoundedContextA .
Pour toute orchestration "détenue" par BoundedContextA , j'aurais un autre événement de gestion de point final / file d'attente qui se rapporte à l'orchestration. Ce point de terminaison ne gère pas uniquement les messages liés à BoundedContextA mais également les messages d'autres BC qui peuvent être impliqués dans l'orchestration. Ce point de terminaison serait nommé selon les lignes de System.BoundedContextA.Orchestration .
Les points de terminaison peuvent être mis à l'échelle horizontalement et c'est particulièrement facile lors de l'utilisation de RabbitMQ.
Merci beaucoup, mais je ne comprends pas ce que vous entendez par orchestration, pouvez-vous l'expliquer?
C'est bon, je l'ai obtenu d'ici youtube.com/watch?v=9gW9WTu1pS4 . Merci encore.
Juste pour confirmer, lors de l'examen d'un processus métier, une orchestration se produit lorsqu'un microservice agit comme le microservice maître, donnant des tâches à d'autres microservices de travail, en autre pour terminer le processus métier. Les autres ne se tiennent pas seuls, ils sont là pour soutenir le maître.
Donc, pour revenir à notre préoccupation, un microservice peut être impliqué dans de nombreuses orchestrations, certaines où il s'agit d'un worker, et d'autres où il est le maître, et chacune de ces orchestrations méritera une file d'attente, n'est-ce pas?
C'est comme avoir une file d'attente par processus métier, et un seul microservice peut être impliqué dans de nombreux processus métier.
Je n'irais pas jusqu'à avoir une file d'attente par processus ou type de message bien que vous puissiez configurer vos points de terminaison en tant que tels. Le microservice / point d'extrémité BC "de base" ne concerne que la fonctionnalité du BC et à toutes fins utiles, d'autres BC n'existent pas pour lui. Le point de terminaison d'orchestration agit comme une sorte de couche d'intégration et interagit généralement avec divers BC. En utilisant mon bus de service (Shuttle.Esb) dans l'espace .Net, un seul point de terminaison peut gérer plusieurs messages ou être configuré pour être plus précis en traitant des messages spécifiques en fonction de ce qui arrive dans la file d'attente de la boîte de réception.
La conception basée sur le domaine elle-même ne prescrit pas de tels modèles ou directives. Mais cela prescrit de concevoir autour de votre domaine , et non autour des détails de l'infrastructure tels que les courtiers, les files d'attente, etc.
Cela dit; et en supposant que vous fassiez de la POO, traiter vos objets de domaine comme des citoyens de premier ordre signifiera probablement que vous dissociez complètement votre domaine de votre infrastructure et inviterez ainsi des modèles courants qui sont bons dans ce domaine, tels que architecture hexagonale .
Même dans ce cas, DDD ne prescrit pas non plus d'approche d'intégration particulière; Le fait que vous posiez des questions sur les files d'attente indique que vous envisagez une intégration asynchrone . Il n'y a rien de mal à cela, mais il est toujours avantageux de reporter les décisions d'architecture . Surtout si vous êtes "sur le point" de découvrir ce domaine via DDD. Essayez de démarrer simple , faiblement couplé mais monolith-first , vous découvrirez peut-être que vous n'avez même pas besoin de files d'attente du tout.
Après avoir pris en compte tout ce qui précède, dans un scénario d'intégration asynchrone avec RabbitMQ, il est courant d'utiliser un modèle pub-sub . Tous les événements pertinents sont publiés dans un échange sans avoir à l'esprit un consommateur spécifique. Les consommateurs configurent leurs propres files d'attente et liaisons selon leurs besoins, il n'y a donc pas de formule unique qui fonctionne:
Merci. J? ai compris. Quand on comprend que chaque consommateur a configuré ses files d'attente, tout devient clair, il a juste besoin de savoir où publier ses résultats. Je mets les files d'attente au pluriel car un consommateur peut s'abonner à de nombreuses files d'attente. Pensez-vous que c'est une bonne chose? Le consommateur doit-il être divisé en plusieurs consommateurs, un pour chaque file d'attente? ou ces files d'attente devraient-elles être fusionnées en une seule?
@acmoune "résultats" sous la forme de plus d'événements, sont publiés à ce même échange pour toute partie intéressée. Si vous pensez à des résultats de style de requête, ceux-ci devraient probablement être traités de manière synchrone, c'est-à-dire: juste du code (domaine intégré), REST, etc. «consommateur» est ici un terme vague; si vous voulez dire service / déployable, utilisez UN SEUL jusqu'à ce que cela soit évident (encore une fois, monolithique d'abord, pas de microservices). D'après mon expérience, il est plus facile à exécuter si vous avez des files d'attente par type de message, mais cela dépendra des modes d'échec et de la manière dont votre domaine et votre implémentation tolèrent les événements dans le désordre.