La messagerie asynchrone (en particulier la messagerie de style pub / sous) est-elle viable en tant qu'architecture de service de domaine ou uniquement dans un environnement orienté SOA?

Question

J'ai effectué des recherches sur la messagerie asynchrone et j'apprécie son traitement élégant des problèmes de certains domaines et la plus grande explication des concepts de domaine. Mais s'agit-il d'un modèle viable pour le développement général axé sur le domaine (au moins dans la couche service / application / contrôleur), ou la surcharge de conception est-elle telle qu'elle devrait être limitée aux scénarios basés sur la SOA, tels que les services distants et le traitement distribué?

Answer 1

Excellente question :). Le principal problème de la messagerie asynchrone est que, lorsque les utilisateurs utilisent des langages procéduraux ou orientés objet, travailler de manière asynchrone ou en fonction d'événements est souvent assez délicat, complexe et difficile à lire et à lire; comprendre. La logique métier est souvent beaucoup plus simple si elle est construite de manière un peu synchrone: invocation de méthodes et obtention immédiate des résultats, etc.:).

Mon principe consiste généralement à essayer d'utiliser des modèles de programmation synchrones plus simples au niveau micro pour la logique métier; utilisez ensuite asynchronisme et SEDA au niveau macro.

Par exemple, l'envoi d'un bon de commande peut simplement écrire un message dans une file d'attente de messages; Toutefois, le traitement de la commande d'achat peut nécessiter 10 étapes différentes, toutes asynchrones et parallèles dans un système distribué hautes performances comportant de nombreux processus simultanés. les threads traitant des étapes individuelles en parallèle. Le câblage au niveau macro est donc basé sur une approche de type SEDA - mais au niveau micro, le code des 10 étapes individuelles pourrait être écrit principalement dans un style de programmation synchrone.

Answer 2

Comme pour de nombreuses questions d’architecture et de conception, la réponse est "cela dépend".

Selon mon expérience, la force de la messagerie asynchrone réside dans le couplage lâche qu’elle apporte à la conception. Le couplage peut être dans:

• Heure: les demandes peuvent être traitées de manière asynchrone, ce qui facilite l'évolutivité globale.
• Espace - Comme vous l'avez souligné, le traitement distribué permet une exécution plus robuste que de nombreuses conceptions synchrones.
• Technologie - Les messages et les files d’attente sont un moyen de surmonter les différences technologiques.

N'oubliez pas que les messages et les files d'attente constituent une abstraction pouvant avoir diverses implémentations. Vous n'avez pas nécessairement besoin d'utiliser une infrastructure de messagerie hautes performances, transactionnelle et conforme à JMS. Mis en œuvre correctement, une table dans une base de données relationnelle peut servir de file d'attente avec les lignes sous forme de messages. J'ai vu les deux approches utilisées à bon escient.

Answer 3

Je suis aussi d'accord avec @BradS BTW

BTW voici un moyen de masquer le middleware de votre logique métier pendant que toujours profiter des avantages d’un couplage lâche & amp; SEDA - tout en étant capable de basculer facilement entre diverses technologies de middleware - de SEDA en mémoire à JMS en passant par AMQP en passant par JavaSpaces, une base de données, des fichiers ou FTP, etc.