Dans cet article
Utiliser une commande pour éprouver les frontières
Imaginons un produit avec catalogue, commandes et facturation. Un monolithe modulaire peut les conserver dans un déploiement unique avec des interfaces explicites. Le module commande ne devrait pas modifier directement les tables de facturation simplement parce que la base est commune. Une frontière utile rend les responsabilités visibles avant de devenir une frontière réseau.
Parcourez le scénario « annuler après émission de facture ». Quel module autorise l’annulation ? Quels enregistrements doivent changer ensemble ? Où se fait la compensation ? Si l’équipe ne sait pas répondre dans un seul processus, répartir le code distribuera l’ambiguïté. Des outils comme Spring Modulith aident à modéliser les modules ; les décisions métier restent à construire par l’équipe.
Où se situe la frontière ?
Les deux approches nécessitent une responsabilité métier claire.
Monolithe modulaire
Des modules dans un même déploiement. Les frontières sont appliquées dans l’application.
Microservices
Des déploiements indépendants. Les frontières traversent aussi réseau, données et exploitation.
Partir de la plus petite frontière exploitable
Un monolithe modulaire conserve déploiement, observabilité et cohérence des données dans une unité exploitable tout en imposant des frontières de domaine dans le code. C’est souvent la baseline la plus sûre lorsqu’une équipe porte le produit et que les workloads partagent le même rythme de release.
Les microservices deviennent utiles lorsque les contraintes d’autonomie, de scalabilité, de disponibilité ou de release sont réelles et durables. Découper trop tôt transforme simplement des frontières de code en frontières réseau, données et incidents.
Tester les frontières avant de les distribuer
Définissez les modules autour des capacités métier, rendez explicite le sens des dépendances et interdisez l’accès direct aux tables d’un autre module. Si le modèle modulaire ne tient pas dans un processus, les API et queues ne le rendront pas plus clair.
Observez quels modules changent ensemble, se disputent des ressources ou exigent une fiabilité différente. Ces signaux sont plus solides pour décider une extraction que le nombre de classes ou la taille du repository.
Extraire avec un plan de reprise
Avant d’extraire un service, nommez un responsable et définissez son autorité sur les données, ses comportements d’échec, sa fenêtre de compatibilité, sa télémétrie et son rollback. Des doubles écritures sans réconciliation créent deux vérités concurrentes.
Extrayez une seule frontière justifiée, mesurez si elle supprime la contrainte initiale et gardez le reste du système simple. Une architecture distribuée est un engagement d’exploitation continu, pas un refactoring ponctuel.
Ce que l’extraction ajoute à une demande ordinaire
Une fois la facturation extraite, une commande peut être acceptée alors que la facture tarde. L’interface doit montrer cet état intermédiaire. Une reprise ne doit pas émettre une deuxième facture ; un ancien événement ne doit pas écraser une annulation récente. Ce sont des comportements produit autant que des sujets d’infrastructure.
Avant l’extraction, dessinez les états et le responsable de chaque transition. Où le client voit-il « en attente » ? Quel traitement rapproche les opérations inachevées ? Qui enquête sur un dossier bloqué ? Si chaque modification nécessite une transaction globale, réinterrogez la frontière. Garder ensemble des fonctions étroitement liées peut être plus cohérent tant que le métier ne peut pas accepter et expliquer une progression partielle.
Extraire une capacité et vérifier le résultat
Une extraction convaincante répond à une contrainte précise : rythme de livraison distinct, équipe responsable autonome ou profil de ressources différent. Mesurez la situation initiale. Déplacez ensuite une interface et la responsabilité de ses données, conservez la compatibilité pendant le déploiement et vérifiez que la contrainte diminue réellement.
Examinez la coordination des versions, la charge d’astreinte et le temps nécessaire pour suivre une demande client. Si chaque évolution impose toujours de déployer toutes les équipes ensemble, vous avez peut-être créé un monolithe distribué. Suspendez les extractions jusqu’à comprendre ce couplage. L’objectif est d’aligner frontières et travail, pas d’atteindre un nombre de services ou un schéma plus sophistiqué.
Sources et lectures complémentaires
Documentation consultée le .
FAQ / DÉCISIONS
Questions fréquentes
Les microservices scalent-ils mieux par défaut ?+
Non. Ils permettent une scalabilité indépendante lorsque les frontières et workloads le justifient, mais ajoutent des coûts réseau, de cohérence, de déploiement et d’incident.