On croit souvent qu’avoir découpé le monolithe en plusieurs services, c’est avoir découplé. Le code est réparti, chaque équipe a son dépôt, on coche la case. Sauf que si ces services lisent et écrivent tous dans les mêmes tables, vous n’avez rien séparé du tout : vous avez déménagé le couplage du code vers le schéma. Et c’est un déménagement qui ne se voit pas, ce qui le rend bien plus dangereux que celui qu’on croit avoir réglé.
Tant que plusieurs services écrivent dans les mêmes tables, le couplage a juste glissé du code vers le schéma. Le seul vrai découplage rend chaque domaine seul propriétaire de ses données.
Le couplage a changé d’adresse
Voilà ce qui se passe concrètement. Vous extrayez un service du monolithe, il démarre, les tests passent, vous enchaînez. Mais ce service et le monolithe continuent de taper dans les mêmes tables. Renommez une colonne, et plusieurs services tombent d’un coup. N’importe quel composant peut écraser les données d’un autre sans contrat ni garde-fou. Faire évoluer le modèle d’un domaine devient impossible sans risquer d’en casser un voisin.
Un cas qui m’a marqué : une PME logistique, une vingtaine de tables, un service « expéditions » fraîchement extrait qui continuait pourtant à écrire dans le stock en direct. Deux semaines après la mise en prod, un correctif sur le stock côté monolithe a silencieusement faussé les expéditions pendant trois jours. Personne n’avait fait le lien, parce que rien dans le code ne reliait visiblement les deux services. Le fil, il était dans la base.
La propriété, et comment l’installer
Le principe tient en une phrase : chaque domaine possède ses données et reste seul à y écrire. Les autres n’y touchent jamais en direct. Le domaine commandes ne fouille pas la table clients, il demande au service clients, par un appel ou un événement. À partir de là, chacun fait évoluer son modèle interne librement, derrière un contrat qui, lui, ne bouge pas.
Pour y arriver, l’ordre des gestes compte plus qu’on ne le pense. D’abord, désigner le propriétaire de chaque jeu de données : c’est souvent évident, et quand ça ne l’est pas, c’est que vos frontières métier sont floues, ce qu’il faut régler avant tout le reste. Ensuite, couper les écritures croisées : seul le propriétaire écrit, les autres passent par lui. C’est le geste qui rapporte le plus, attaquez-le en premier. Vient seulement après la séparation des lectures, en remplaçant les SELECT directs par un appel ou une copie locale alimentée par événements. Quant à séparer physiquement les bases, ce n’est pas un préalable mais un aboutissement, le jour où le besoin l’exige. Sur la PME logistique, on a coupé l’écriture croisée d’abord ; le reste a suivi sur un trimestre.
Le geste qui décide
Si vous ne deviez retenir qu’une action, ce serait celle-ci : ouvrez la gestion des droits de votre base et retirez les permissions d’écriture des comptes applicatifs qui ne sont pas propriétaires, table par table. Un service à qui la base n’a pas accordé le droit d’écrire (le GRANT, l’autorisation explicite gérée par la base elle-même) ne peut pas tricher, même un vendredi soir, même quand vous n’êtes plus là pour surveiller. C’est moins satisfaisant qu’un beau document d’architecture, mais un document ne s’applique pas tout seul un dimanche à 3 h du matin. Un droit SQL, si.
À lire aussi
- Sortir du monolithe
- Communication entre services : synchrone ou événementielle ?
- Découper un monolithe sans casser la production
- Architecture événementielle : quand elle aide, quand elle complique
- Introduire un bus de messages (NATS) dans une application existante
- Mesurer la dette technique pour prioriser le découpage