Chaque diagramme de microservices commence propre et finit en pelote. C'est presque une loi. Vous dessinez les services, puis les appels entre eux, et au bout de vingt boîtes c'est un maillage illisible de flèches qui se croisent et ne vous dit rien d'autre que « c'est compliqué ». Le problème n'est pas l'architecture. C'est que le diagramme essaie de montrer toutes les connexions à la fois, alors que le lecteur a besoin de la forme : les frontières, et la façon dont les services communiquent.
La solution consiste à arrêter de dessiner « chaque service appelle chaque service » et à dessiner plutôt deux choses délibérément : les frontières qui regroupent les services, et le style de communication sur chaque lien. Faites-le et même un grand système reste lisible.
Regroupez par frontière, pas en grille
La plus grande amélioration possible consiste à cesser d'aligner les services dans une grille bien nette et à les regrouper selon la frontière à laquelle ils appartiennent. En termes de domaine, ce sont vos bounded contexts ; en termes d'équipe, c'est généralement qui possède quoi. Commandes, Paiements, Identité, Catalogue. Dessinez-les comme des régions nommées et placez les services à l'intérieur. D'un coup, le diagramme a une structure, et le lecteur peut s'y repérer par zone au lieu de parcourir quarante boîtes identiques.
Montrez le style de communication sur chaque lien
Toutes les flèches ne se valent pas, et faire comme si c'était le cas explique pourquoi les diagrammes de microservices induisent en erreur. Une requête synchrone (un service en appelle un autre et attend) a un comportement de défaillance et de latence complètement différent d'un événement asynchrone (un service publie, les autres réagissent quand ils le peuvent). Dessinez-les différemment : traits pleins pour les appels synchrones, pointillés pour les événements passant par un bus ou une file d'attente. Le diagramme raconte alors une histoire opérationnelle. Vous voyez où un service lent provoquera une cascade (les chaînes en traits pleins) et où le système est découplé (les sauts en pointillés).
Deux types de flèches, dessinées différemment, transforment une pelote en carte de l'endroit où la défaillance se propage et de celui où elle s'arrête.
Dessinez la propriété des données, au moins une fois
La règle qui fait des microservices des microservices, c'est que chaque service possède ses données. Un diagramme qui montre tous les services partageant une seule base de données dessine un monolithe distribué, que l'équipe le veuille ou non. Il vaut la peine d'avoir une vue où chaque service se trouve avec son propre stockage, car dès que deux services pointent vers la même base de données, vous avez trouvé un couplage qui fera mal plus tard. Vous n'en avez pas besoin sur chaque diagramme, mais il vous la faut quelque part.
Ajoutez les éléments qui appartiennent à tous
Quelques composants se trouvent hors des frontières et touchent à tout : l'API gateway qui sert de façade à tout le système, le bus d'événements ou le broker de messages qui transporte le trafic asynchrone, et, si vous en exploitez un, le service mesh qui gère les questions de service à service. Donnez-leur leur propre place en bordure du diagramme pour qu'ils se lisent comme une infrastructure partagée, et non comme un service de plus dans une boîte.
Résistez à l'envie de tout dessiner
Le diagramme de microservices raté cherche à être complet. Le diagramme utile est délibérément partiel. Choisissez la question à laquelle il répond (comment une requête circule, où se trouvent les frontières asynchrones, quels services possèdent quelles données) et ne dessinez que ce qui la sert. Complet mais illisible n'aide personne ; ciblé et clair, c'est tout l'objectif.
Gardez-le vivant
Les systèmes de microservices changent plus vite que presque tout ce que vous pourriez représenter en diagramme : nouveaux services, nouveaux événements, dépendances retirées. Une version dessinée à la main est obsolète avant la fin du sprint. Dérivez le squelette de la source (spécifications, manifestes de services ou graphe d'appels), régénérez-le à mesure qu'il évolue, et gardez votre regroupement par frontières et le style des liens comme couche humaine par-dessus. Ainsi, le diagramme suit le rythme d'un système dont toute la promesse est de changer de façon indépendante.
Regroupez par frontière, stylez les liens selon la façon dont les services communiquent, montrez la propriété des données une fois et générez la base pour qu'elle reste à jour. Voilà un diagramme de microservices qui clarifie au lieu d'intimider.