Les diagrammes se remplissent de petits rectangles appelés microservices. Chaque service possède une capacité, se déploie seul et peut choisir son stockage. Cette autonomie peut aider une grande organisation. Elle transforme aussi des appels de méthode fiables en réseau, versions et données distribuées.

Je découperais selon une responsabilité métier, pas selon les couches techniques. Un service Commandes possède l’état de commande; Inventaire possède la réservation. Ils communiquent par contrat. Aucun ne lit directement les tables de l’autre, sinon le déploiement indépendant disparaît.

Une commande sans transaction distribuée

Le flux peut suivre une saga :

1. Commandes crée en_attente avec identifiant unique;
2. il publie CommandeCreee;
3. Inventaire réserve et publie StockReserve;
4. Paiement autorise et publie PaiementAutorise;
5. Commandes passe confirmee;
6. si le paiement refuse, Inventaire reçoit LibererReservation.

Chaque service écrit son état et son événement dans la même transaction locale via une outbox. Les consommateurs sont idempotents. La cohérence est éventuelle : pendant quelques secondes, un écran peut voir une commande en attente. L’interface doit présenter cet état, pas inventer un succès instantané.

Une compensation n’est pas un rollback parfait. Libérer du stock est possible; annuler un courriel déjà reçu ne l’est pas. Le design doit distinguer actions réversibles, compensables et irréversibles, puis repousser les dernières lorsque possible.

Le réseau est maintenant dans le code

Chaque appel synchrone possède timeout, budget total et disjoncteur. Une chaîne de cinq services à 99,9 % de disponibilité chacun donne moins que 99,9 % pour le parcours complet. Les caches et modes dégradés doivent respecter la vérité métier; afficher un vieux prix comme actuel peut être pire qu’un refus.

Les logs ont une corrélation commune, les métriques suivent latence et erreurs par frontière, et les traces permettent de retrouver une commande. Le registre de services, DNS, certificats et files deviennent des dépendances de production.

La sécurité exige une identité de service, des rôles minimaux et une rotation des secrets. Un périmètre interne n’est pas fiable par défaut. Les schémas sont versionnés avec compatibilité descendante; ajouter avant de retirer évite de coordonner tous les déploiements.

Maintenir un contrat sans déploiement collectif

Le producteur publie un schéma d’événement avec exemples. Un test de consommateur décrit les champs et règles dont il dépend; le pipeline du producteur exécute ces contrats avant la mise en ligne. Pour remplacer prix par montant, on ajoute le nouveau champ, remplit les deux, migre les lecteurs puis retire l’ancien après observation. Un registre indique les versions encore reçues. Les messages inconnus vont en quarantaine plutôt que planter le processus. Cette compatibilité progressive permet l’autonomie promise. Si chaque changement impose une réunion et une heure commune aux dix services, le découpage a déplacé le monolithe dans le calendrier.

Je n’utiliserais des microservices que si l’autonomie de déploiement ou d’échelle rembourse ce coût. Pour un petit domaine, un monolithe modulaire avec frontières et une seule transaction sera souvent plus simple. Mon test est concret : l’équipe peut-elle posséder le service, ses données, ses alertes et sa reprise de bout en bout? Si non, le rectangle est seulement plus loin.