Découper un monolithe .NET

Personne ne peut geler un produit pendant un an pour le réécrire. Découper un monolithe, c’est sortir un service à la fois, en production, pendant que l’équipe continue de livrer.

Commencer par les frontières, pas par le code

Avant de créer un projet, je cherche les frontières métier : les endroits où le vocabulaire change. « Client » ne veut pas dire la même chose pour la facturation et pour le support. Chaque frontière est un candidat.

Choisir le premier service pour apprendre, pas pour impressionner

Le premier service doit être peu couplé, utile et réversible. On y met en place tout ce qui servira aux suivants : pipeline, observabilité, gestion des secrets, contrat d’API, publication d’événements.

Étrangler, pas remplacer

Une passerelle (API Management ou YARP) se place devant le monolithe. Les appels vers la fonctionnalité extraite partent vers le nouveau service ; le reste continue d’aller au monolithe. On bascule route par route, et on peut revenir en arrière.

Les données d’abord séparées logiquement

Le nouveau service possède ses tables, même si elles restent un temps dans la même base. Le monolithe n’y écrit plus directement : il passe par l’API ou par un événement. La séparation physique vient ensuite, sans risque.

Des événements pour défaire les jointures

Là où le monolithe faisait une jointure entre deux domaines, le service publie un événement (« commande validée ») que l’autre domaine consomme pour tenir sa propre copie. Service Bus fait très bien ce travail.

Mesurer avant, mesurer après

Temps de réponse, taux d’erreur, fréquence des déploiements : on les mesure avant de commencer. Sans point de départ, impossible de dire si le découpage a servi à quelque chose.