Approche par Composants en Architecture Logicielle

# Architecture basée sur les composants : du monolithe aux systèmes évolutifs

L'architecture basée sur les composants traite les répertoires comme des blocs de construction sur un schéma et les dépendances comme des lignes de connexion. Chaque composant est un répertoire de code compilé en bibliothèque. Les dépendances sont gérées par l'outil de build — par exemple, crm/core intègre crm/api et payments/api pour se connecter à une passerelle de paiement.

Cela crée une imbrication naturelle, comme un système de fichiers, tout en assurant une interopérabilité fluide. Cette approche fonctionne avec n'importe quel outil de build moderne et langage, en passant des monolithes aux microservices.

API et SPI pour l'abstraction des données

Séparez la logique métier principale de l'infrastructure grâce au pattern API-SPI. L'API est le contrat exposé par votre application (comme une interface CRM). Le SPI est le contrat pour les fournisseurs externes (Postgres pour le stockage, TigerBeetle pour les paiements).

Avantages clés :

• La logique principale reste indépendante des bases de données ou services spécifiques.
• Échangez les implémentations sans reconstruire le cœur.
• Supportez plusieurs fournisseurs dans un seul processus de démarrage.

Le schéma place core entre api et spi, les composants d'infrastructure implémentant le SPI.

Bootstrap pour l'assemblage de l'application

Créez un composant bootstrap comme une dépendance plug-and-play. Il relie les implémentations SPI aux API dans le contexte de l'application. Les frameworks modernes résolvent les dépendances automatiquement ; en langages simples, utilisez la configuration de build.

Exemple : Un bootstrap CRM connecte crm/core et payments/core via un contexte partagé. Cela simplifie le déploiement — ajoutez la dépendance, et c'est prêt.

Évolution vers les microservices

Pour une scalabilité indépendante, décomposez le monolithe :

• Extrayez des applications autonomes pour CRM et paiements.
• Ajoutez un rest-client dans CRM qui implémente l'API Paiements via HTTP.
• Dans paiements, ajoutez un rest-server qui proxy vers payments/core via bootstrap.
• Partagez les DTO communs dans rest-common.
• Intégrez le client dans le bootstrap CRM.

Résultat : Un cluster avec contextes délimités, où les composants scalent indépendamment.

Composants de plateforme

Extrayez les solutions partagées dans une plateforme pour respecter le principe DRY :

• Configurations Postgres et TigerBeetle.
• Communication client/serveur REST.
• Authentification, messagerie asynchrone/synchrone et stockage.

La plateforme réduit la duplication : les composants s'intègrent avec des setups prêts à l'emploi. Passez de la réutilisation basique à des solutions enterprise.

Avantages et gouvernance

Les composants imposent des frontières claires selon la loi de Conway : assignez-les à des équipes et suivez les interactions.

Gestion du cycle de vie : Les petits composants sont faciles à échanger et migrer.

Restez focalisé sur les besoins : Les abstractions permettent de choisir des stacks selon les KPI (performance, coût), pas les habitudes.

Quand l'utiliser

Adoptez-la dès le premier jour : des prototypes aux systèmes distribués. Compatible avec tout outil de build, scalable aux repos et équipes. Évitez la « grosse boule de boue » — les composants permettent une évolution fluide.

Points clés :

• Répertoires granulaires comme unités de déploiement et de responsabilité.
• API/SPI pour découpler de l'infrastructure.
• Bootstrap pour assemblage automatique du contexte.
• Plateforme pour un DRY maximal et réutilisation.
• Transition monolithe-microservices sans refactoring du cœur.

— Editorial Team