Modèles de Communication des Monolithes Modulaires

Les monolithes modulaires gagnent en popularité dans la communauté de l'ingénierie logicielle. L'attrait des microservices devient moins convaincant, et les vétérans expérimentés de notre industrie suggèrent de reconsidérer cette approche :

"Vous ne devriez pas commencer un nouveau projet avec des microservices, même si vous êtes sûr que votre application sera assez grande pour en valoir la peine." — Martin Fowler

Les monolithes modulaires offrent l'architecture logique des microservices sans la complexité opérationnelle. Vous pouvez déterminer en toute sécurité les limites entre les modules, et le refactoring est simple et moins risqué. Ils peuvent également être facilement migrés vers des microservices si vous décidez de le faire.

Dans cet article, je souhaite me concentrer sur les modèles de communication dans l'architecture des monolithes modulaires.

Qu'est-ce qu'un Monolithe Modulaire ?

Un Monolithe Modulaire est une approche de conception logicielle dans laquelle un monolithe est conçu avec un accent sur des modules interchangeables (et potentiellement réutilisables).

Le problème avec la plupart des systèmes monolithiques est qu'ils deviennent fortement couplés avec le temps. Les composants deviennent profondément entremêlés, rendant les changements dans un composant impactant de nombreux autres. L'introduction de nouvelles fonctionnalités devient difficile et sujette aux erreurs.

Les monolithes modulaires visent à résoudre ces problèmes.

Un monolithe modulaire se compose de nombreux modules faiblement couplés. Les modules représentent des ensembles cohérents de fonctionnalités et sont indépendants les uns des autres. Voici quelques exemples :

• Module de paiements
• Module d'expédition
• Module de réservation
• Module d'avis

Si ce concept vous rappelle les microservices, c'est normal. Les microservices représentent des services autonomes encapsulant un ensemble de fonctionnalités du système plus large, tout comme les modules dans un monolithe modulaire.

Pour qu'un monolithe modulaire soit faiblement couplé, vous devez résoudre la question de la communication entre les modules. Les modules ne peuvent pas se référencer directement les uns les autres, sauf via leurs API publiques.

Il existe deux modèles de communication largement utilisés. Les deux ont des avantages et des inconvénients et un ensemble de compromis que vous devez comprendre.

Communication Synchrone avec Appels de Méthodes

Le premier et le plus simple modèle de communication est les appels de méthodes simples entre les modules. Les appels de méthodes sont synchrones et très rapides car ils se font en mémoire.

Le Module A appelle une méthode déclarée sur l'API publique du Module B et attend de recevoir un résultat. Chaque module expose une API publique, qui peut être une interface en .NET.

Le module implémente cette interface en interne et cache tous les détails d'implémentation. Vous pouvez utiliser le mot-clé internal pour rendre l'implémentation inaccessible en dehors du module.

Les modules dépendent des interfaces au moment de la compilation (compile-time). À l'exécution (runtime), l'injection de dépendances fournira l'implémentation respective.

Avantages :

• Vitesse des appels en mémoire
• Facile à mettre en œuvre
• Pas d'indirection

Inconvénients :

• Couplage fort : La communication synchrone signifie que les modules seront fortement couplés. Si l'un des modules est indisponible, cela affectera tous les modules dépendants. Vous pouvez introduire un mécanisme de retry, mais cela ne va pas très loin.

Communication Asynchrone avec Messagerie

Le second modèle de communication est la messagerie asynchrone entre les modules. Le Module A envoie un message au courtier de messages de manière "fire-and-forget". Le Module B s'abonne aux messages pertinents et les traite en conséquence.

Les modules n'ont pas besoin de se connaître, mais ils doivent connaître les contrats de messages.

Les contrats de messages sont l'API publique d'un module dans ce scénario.

Avantages :

• Haute disponibilité
• Couplage faible : La communication asynchrone nous donne un couplage faible car les modules communiquent à l'aide de messages. Le Module B n'a pas besoin d'être disponible pour que le Module A envoie un message.

Inconvénients :

Complexité accrue : Nous introduisons un courtier de messages (message broker) dans le système. C'est un autre composant d'infrastructure que nous devons gérer.

C'est aussi un point de défaillance unique. Si le courtier de messages échoue, la communication entre les modules échoue aussi.

Vous pouvez éviter la perte de messages en les stockant dans une Outbox avant de les publier. Nous pouvons toujours renvoyer les messages à partir de la base de données en cas de défaillance du courtier de messages.

Conclusion

La communication synchrone entre les modules est facile à mettre en œuvre et performante, mais elle entraîne un couplage étroit entre les modules. La communication asynchrone utilisant un courtier de messages est faiblement couplée mais plus complexe à mettre en œuvre.

Alors, quel modèle de communication devez-vous utiliser ? Cela dépend.

La communication asynchrone peut vous aider à construire des modules faiblement couplés et indépendants. La migration d'un monolithe modulaire utilisant la messagerie vers un système distribué est beaucoup plus facile. Vous extrayez un module dans son propre unité de déploiement, et la communication entre les modules reste la même. Parce que vous utilisez la messagerie, vous n'avez pas besoin de réimplémenter quoi que ce soit.

Les appels de méthodes synchrones sont un excellent choix pour augmenter la vélocité de développement et réduire la complexité opérationnelle.

Je laisse le soin à l'architecte logiciel en vous de décider.

Merci de m'avoir lu.