Vous n’avez pas besoin de microservices, mais de meilleures frontières de domaine

Depuis des années, les microservices ont acquis une aura quasi informelle de maturité architecturale. Dans beaucoup d’entreprises, il suffit que le système prenne un peu d’ampleur, que les déploiements deviennent gênants et que deux ou trois équipes commencent à intervenir sur la même base de code pour que la question apparaisse à la table : « n’est-ce pas le moment de le découper en services ? »

La question paraît moderne. Le problème, c’est que, bien souvent, elle arrive trop tôt.

En pratique, une grande partie des équipes ne souffre pas parce qu’elle est dans un monolithe. Elle souffre parce qu’elle évolue dans un système sans frontières de domaine claires, sans ownership bien défini et sans une séparation cohérente entre des parties qui changent pour des raisons différentes. Quand cela se produit, adopter les microservices ne résout pas la racine du problème. Cela ne fait que répartir la confusion sur davantage d’endroits, avec des coûts opérationnels accrus et davantage de points de défaillance.

La provocation de cet article est simple : peut-être que votre système n’a pas besoin de microservices. Peut-être qu’il a besoin de frontières de domaine plus nettes.

Le mythe de la maturité architecturale par la distribution

Il existe une narration particulièrement séduisante dans le domaine technologique : les systèmes petits commencent simples, évoluent et, à un moment donné, « naturellement », deviennent des microservices. Comme si cela constituait une ligne inévitable de progrès.

Dans la pratique, cela ne fonctionne pas ainsi.

Beaucoup d’équipes confondent l’architecture nécessaire avec l’architecture aspirational. Elles regardent des entreprises à l’échelle massive, assistent à des conférences sur les écosystèmes distribués, des pipelines sophistiqués, des service meshes, des files d’attente, une observabilité avancée et concluent que cela représente l’étape suivante pour tout produit en croissance.

Cependant, il existe presque toujours un détail ignoré dans cette comparaison : les grandes architectures distribuées ont été conçues pour résoudre de vrais problèmes d’échelle organisationnelle, de domaine, de débit, de résilience et d’autonomie des équipes. Elles ne sont pas apparues pour paraître modernes.

Quand une entreprise adopte trop tôt les microservices, ce qui entre dans le paquet n’est pas seulement « casser le système ». Il s’agit aussi de nouvelles exigences :

• traçage distribué
• contrats entre services
• politiques de réessai et de délais d’attente
• observabilité plus mature
• authentification et autorisation entre composants
• versionnage de l’intégration
• consistance éventuelle
• dépannage plus difficile
• déploiement distribué
• coût opérationnel plus élevé

C’est le point que beaucoup de décisions hâtives négligent. Les microservices ne sont pas seulement une manière différente d’organiser le code. C’est une manière différente d’exploiter l’ensemble du système.

Si le vrai problème reste un couplage de domaine mal résolu, la distribution devient une dette technique distribuée.

Le vrai problème : des parties du système sans frontières claires

En architecture logicielle, presque tout s’améliore lorsque les parties du système ont des responsabilités claires, un rythme de changement cohérent et une ownership bien définie.

Le nom sophistiqué peut varier. Vous pouvez parler de bounded context, de frontière métier, de module de domaine, de frontière fonctionnelle. Le nom importe moins que la conséquence pratique : les parties qui changent ensemble devraient être pensées ensemble, et les parties qui existent pour des raisons différentes ne devraient pas être mélangées par hasard.

C’est ici que beaucoup d’architectures échouent.

Plutôt que de séparer le système selon ce que fait réellement le métier, de nombreuses équipes opèrent une séparation selon ce qui paraît le plus apparent techniquement. C’est ainsi que naissent des décompositions telles que celle-ci :

user-service
order-service
product-service
payment-service

À première vue, cela peut sembler organisé. Chaque entité a son propre service. Mais une entité n’est pas un domaine. Une table n’est pas un contexte métier. Et CRUD n’est pas une architecture.

Quand la séparation naît uniquement de la structure des données et non du flux réel du métier, le résultat ressemble typiquement à ceci :

• beaucoup d’appels entre services pour accomplir un seul cas d’utilisation
• des contrats fragiles
• logique dispersée
• ownership nébuleux
• difficulté de savoir où une règle vit réellement

Le système est devenu plus distribué, mais pas plus clair.

Frontières de domaine en pratique

La façon la plus utile de penser les frontières de domaine n’est pas philosophique, mais opérationnelle. Demandez :

• qu’est-ce qui change ensemble ?
• qu’est-ce qui devrait relever de la même équipe ?
• quelle partie du système possède ses propres règles, son propre rythme et son propre impact ?
• où finit un contexte et où commence un autre ?

Un exemple simple d’e-commerce aide beaucoup.

Vous pourriez avoir :

• catalogue, axé produit, classification, attributs, prix de base et exposition commerciale
• checkout, avec une forte responsabilité sur les règles d’achat, le panier, la validation, le paiement et la clôture
• fulfillment, axé sur la séparation, l’expédition, la logistique et le statut opérationnel
• relation client, avec l’historique, le support, les tickets et la communication

Ces domaines dialoguent bien sûr. Mais ils ne changent pas pour les mêmes raisons.

Le catalogue peut changer par décision commerciale. Le checkout peut changer pour des raisons fiscales, en fonction des modes de paiement ou des politiques promotionnelles. Le fulfillment peut changer en raison d’intégrations logistiques, d’un SLA ou d’opération. Le service client peut changer en raison d’une stratégie de support et de CRM.

Ce type de lecture est bien plus utile que de se contenter de demander « combien d’entités existent ici et comment les décomposer en services ? ».

Le domaine mature ne naît pas de la séparation technique. Il naît de la clarté sur les responsabilités, le langage et le flux de changement.

Monolithe modulaire n’est pas un retour en arrière, c’est de la discipline

Voici une conviction forte : beaucoup d’équipes considèrent le monolithe modulaire comme une étape provisoire, presque une contrainte avant la « vraie architecture ». C’est une erreur.

Il existe une différence nette entre :

• un monolithe chaotique, où tout communique avec tout et où personne ne sait où se situe la règle
• et un monolithe modulaire, où les contextes sont bien organisés, avec des contrats internes clairs, une séparation par domaine et des limites respectées au sein de la même base

Un monolithe modulaire peut être un choix extrêmement mûr.

Exemple d’architecture simple :

/src
  /catalog
    /application
    /domain
    /infra
  /checkout
    /application
    /domain
    /infra
  /fulfillment
    /application
    /domain
    /infra

Cela ne se limite pas à une question d’esthétique. Cela réduit le couplage, améliore la lisibilité, apporte une clarté de contexte et prépare le système à des évolutions futures sans imposer, trop tôt, le coût opérationnel d’un environnement distribué.

Dans de nombreux scénarios, cette approche apporte des avantages très concrets :

• debugging plus simple
• observabilité plus directe
• déploiement unique
• moindre complexité d’infrastructure
• moins d’attrition entre modules que entre services séparés
• meilleure vitesse de développement pour des équipes plus petites ou moyennes

Bien sûr, ce n’est pas de la magie. Le monolithe modulaire exige de la discipline. Si les limites sont ignorées, il se dégrade. Si tout continue d’être partagé, cela devient un chaos bien mis en diagramme.

Mais la grande différence est celle-ci : il permet de rechercher une clarté architecturale avant de supporter le coût total de la distribution.

L’erreur classique : distribuer avant de comprendre

Une décomposition mature naît normalement de la clarté. Une décomposition médiocre naît presque toujours de l’anxiété.

L’équipe réalise que le système devient difficile à manipuler et tente de résoudre cela par une séparation physique. Or, la séparation physique ne remplace pas la modélisation. Si le domaine demeure confus, les services commenceront à dépendre les uns des autres pour accomplir des opérations de base.

C’est ici que apparaissent des symptômes bien connus :

• pour finaliser un achat, un service appelle trois autres de manière synchrone
• la logique métier se répand entre plusieurs services
• personne ne sait exactement qui est le propriétaire d’une règle donnée
• affaire d’avoir à aligner plusieurs équipes pour une modification importante
• le dépannage en production devient plus difficile qu’avant
• le déploiement distribué accroît l’attrition sans réduire le risque

Lorsqu’un tel schéma se produit, le système ne devient pas plus découplé. Il devient plus coûteux à accommoder.

Cinq signaux indiquant que la décomposition est arrivée trop tôt

C’est une section précieuse pour les équipes seniors, car elle aide à distinguer la souffrance réelle du battage médiatique autour de l’architecture.

1. L’équipe ne parvient pas encore à nommer clairement les contextes métiers

Si l’architecture s’est déjà transformée en microservices, mais que l’équipe discute encore de « où entre cette règle ? », « qui en est le propriétaire ? » ou « à quel service cela appartient-il ? », le problème est probablement venu avant la distribution.

2. Les services ont été séparés par entité, pas par responsabilité

user-service, product-service et order-service semblent organisés sur le papier, mais cachent souvent des règles qui appartiennent à des flux plus larges et à des contextes plus riches. Séparer par entité peut générer une chorégraphie excessive entre services.

3. Un seul cas d’utilisation exige plusieurs appels synchrones

Si un flux simple nécessite de nombreux sauts entre services pour fonctionner, il est fort probable que la frontière ait été tracée trop tôt ou au mauvais endroit.

4. Le déploiement est devenu plus difficile, pas plus sûr

Les microservices devraient accroître l’autonomie. Si, après la décomposition, l’équipe doit coordonner davantage de changements, faire plus d’alignement et souffre davantage lors de la publication, l’architecture s’est peut-être détériorée.

5. La motivation principale était « il faut moderniser »

Lorsque l’argument central n’est pas un problème concret de domaine, d’échelle, d’autonomie ou d’exploitation, mais une impression diffuse de mise à jour technologique, le risque d’une décomposition prématurée augmente considérablement.

Quand les microservices prennent réellement sens

Cet article n’est pas opposé aux microservices. Ce serait trop simpliste de prendre ce parti.

Les microservices peuvent avoir du sens lorsqu’ils émergent comme conséquence d’une architecture déjà plus claire et de besoins réels mieux définis.

Normalement, cela survient lorsque certains facteurs apparaissent simultanément :

• des contextes métier déjà raisonnablement délimités
• des équipes disposant d’une autonomie réelle sur certaines parties du système
• certaines parties du domaine évoluent à des rythmes très différents
• des composants nécessitent une échelle opérationnelle indépendante
• des dépendances techniques et non techniques qui justifient une séparation
• les coûts de coordination dans un seul déploiement ont fini par devenir trop élevés

Voyez la différence dans la logique.

Dans l’approche impatiente, l’équipe isole le système en espérant que la clarté apparaîtra ensuite.

Dans l’approche mature, la clarté existe déjà à un niveau suffisant, et la séparation devient une conséquence presque naturelle.

Les microservices fonctionnent mieux lorsqu’ils ne servent pas à « découvrir » le domaine, mais à respecter un domaine déjà compris.

Monolithe modulaire versus microservices, sans romantisme

Autant faire une comparaison honnête, sans camp adverse.

Monolithe modulaire

Avantages

• moindre complexité opérationnelle
• debugging plus simple
• moins de friction de communication
• observabilité plus directe
• déploiement unique
• vitesse plus grande pour de nombreux scénarios produit

Inconvénients

• exige une discipline forte pour maintenir des limites internes
• peut se transformer en monolithe chaotique si la modularité n’est pas respectée
• ne résout pas seul des problèmes organisationnels de propriété
• peut commencer à mettre trop de pression sur un seul cycle de déploiement dans des contextes plus avancés

Microservices

Avantages

• déploiement indépendant par contexte
• autonomie accrue pour des équipes mûres
• possibilité de faire évoluer des parties spécifiques du système
• isolation opérationnelle plus fine
• alignement meilleur avec des domaines réellement indépendants

Desavantages

• coût opérationnel élevé
• observabilité plus complexe
• plus grande difficulté de dépannage
• contrats distribués
• risque d’appels excessifs entre services
• nécessité accrue de maturité en plateformes, sécurité et gouvernance

La décision au niveau stratégique ne devrait jamais être « laquelle des deux semble la plus moderne ? ». La bonne question est « laquelle respecte le mieux le stade actuel du domaine, de l’équipe et de l’exploitation ? »

Un cadre simple pour évaluer l’architecture actuelle

Si votre équipe discute actuellement d’évolution architecturale, ces questions sont plus utiles que toute mode passagère.

1. Quelles parties du système changent ensemble ?

Si deux domaines évoluent systématiquement ensemble, il est probable qu’ils appartiennent encore au même contexte.

2. Où le couplage est-il technique et où relève-t-il du métier ?

Tout couplage n’est pas négatif. Des parties du système peuvent partager une trajectoire métier légitime. Le problème survient lorsque le couplage provient d’une mauvaise modélisation, et non d’un besoin réel.

3. Quelles règles sont aujourd’hui trop mêlées ?

Recherchez des zones où le code sert simultanément à des responsabilités différentes. C’est souvent le premier signe d’une frontière mal dessinée.

4. Y a-t-il une véritable ownership ?

Il ne suffit pas que chaque service ait un dépôt séparé. Il faut quelqu’un qui soit propriétaire de l’évolution, de la santé, des contrats et du comportement de cette partie du système.

5. Séparer maintenant réduirait-il le risque ou augmenterait-il seulement l’attrition ?

Cette question est déterminante. Si la séparation n’améliore pas l’autonomie, la clarté et la sécurité opérationnelle, peut-être ne devrait-elle pas avoir lieu pour l’instant.

Ce type de révision est souvent plus productif que de commencer par une discussion sur « quel outil allons-nous utiliser ? » ou « comment décomposons-nous cela en services ? ».

La séniorité apparaît davantage à la frontière qu’à la technologie

L’un des signes les plus forts de maturité technique est d’arrêter de traiter l’architecture comme une collection de technologies et de la considérer comme une décision sur les frontières.

Un développeur senior ayant vécu des incidents, des refontes douloureuses, des migrations qui échouent et des écosystèmes distribués incohérents a tendance à s’en rendre compte plus tôt : le plus grand problème d’un système n’est pas « être en monolithe ». Le vrai problème est souvent de ne pas savoir où commence et se termine une responsabilité.

Lorsque les frontières sont mauvaises, le système souffre, quel que soit le format.

Quand les frontières sont meilleures, même un monolithe vieillit mieux.

Conclusion

Les microservices ne constituent pas une médaille de maturité. Ce sont un outil architectural coûteux, puissant et extrêmement utile dans le contexte adéquat. L’erreur consiste à les traiter comme une destination inévitable plutôt que comme une réponse adaptée à des problèmes spécifiques.

Dans de nombreux systèmes, la discussion sur la distribution commence avant celle sur le domaine. Et cela explique pourquoi tant de décompositions entraînent plus de complexité que de clarté.

Avant de casser le système en services, posez-vous une question plus importante : le domaine est-il déjà suffisamment clair pour soutenir une telle séparation ?

Parce qu’en fin de compte, peut-être que votre système n’a pas besoin de davantage de services. Il pourrait nécessiter des frontières plus nettes.

Révisez l’état actuel du système et identifiez quelles parties du domaine changent ensemble et lesquelles devraient être séparées.