Jedes Microservices-Diagramm beginnt sauber und endet als Knäuel. Das ist fast ein Naturgesetz. Du zeichnest die Services, du zeichnest die Aufrufe zwischen ihnen, und nach zwanzig Kästen ist es ein unlesbares Geflecht aus sich kreuzenden Pfeilen, das dir nichts sagt außer „es ist kompliziert“. Das Problem ist nicht die Architektur. Das Problem ist, dass das Diagramm jede Verbindung gleichzeitig zeigen will, während Lesende die Form brauchen: die Grenzen und die Art, wie Services miteinander reden.
Der Ausweg: Hör auf, „jeder Service ruft jeden Service auf“ zu zeichnen, und zeichne stattdessen bewusst zwei Dinge: die Grenzen, die Services gruppieren, und die Kommunikationsart an jeder Kante. Dann bleibt auch ein großes System lesbar.
Nach Grenzen gruppieren, nicht im Raster
Die größte Verbesserung, die du machen kannst, ist, Services nicht mehr in einem ordentlichen Raster anzuordnen, sondern sie nach der Grenze zu gruppieren, zu der sie gehören. In Domänenbegriffen sind das deine Bounded Contexts; in Teambegriffen meist, wem was gehört. Ordering, Payments, Identity, Catalog. Zeichne sie als beschriftete Bereiche und leg die Services hinein. Plötzlich hat das Diagramm Struktur, und Lesende können sich nach Bereichen orientieren, statt vierzig identische Kästen abzusuchen.
Kommunikation zwischen Microservices: zeig die Art an jeder Kante
Nicht alle Pfeile sind gleich, und so zu tun, als wären sie es, ist der Grund, warum Microservices-Diagramme in die Irre führen. Eine synchrone Anfrage (ein Service ruft einen anderen auf und wartet) hat ein völlig anderes Fehler- und Latenzverhalten als ein asynchrones Event (ein Service veröffentlicht, andere reagieren, wann auch immer). Zeichne sie unterschiedlich: durchgezogene Linien für synchrone Aufrufe, gestrichelte für Events über einen Bus oder eine Queue. Jetzt erzählt das Diagramm eine operative Geschichte. Du siehst, wo ein langsamer Service eine Kaskade auslöst (die durchgezogenen Ketten) und wo das System entkoppelt ist (die gestrichelten Sprünge).
Zwei Arten von Pfeilen, unterschiedlich gezeichnet, machen aus einem Knäuel eine Karte, die zeigt, wo sich Fehler ausbreiten und wo sie aufhören.
Zeichne Datenhoheit, mindestens einmal
Die Regel, die Microservices zu Microservices macht, ist, dass jeder Service seine eigenen Daten besitzt. Ein Diagramm, in dem sich alle Services eine Datenbank teilen, zeigt einen verteilten Monolithen, ob das Team das will oder nicht. Es lohnt sich, eine Ansicht zu haben, in der jeder Service mit seinem eigenen Speicher steht, denn sobald zwei Services auf dieselbe Datenbank zeigen, hast du eine Kopplung gefunden, die später wehtun wird. Du brauchst das nicht in jedem Diagramm, aber irgendwo brauchst du es.
Füge die Kanten hinzu, die allen gehören
Einige Komponenten liegen außerhalb der Grenzen und berühren alles: das API-Gateway vor dem ganzen System, der Event-Bus oder Message Broker, der den asynchronen Traffic trägt, und, falls du eines betreibst, das Service Mesh für die Belange zwischen Services. Gib ihnen einen eigenen Platz am Rand des Diagramms, damit sie als gemeinsame Infrastruktur gelesen werden, nicht als ein weiterer Service in einem Kasten.
Widerstehe dem Drang, alles zu zeichnen
Das gescheiterte Microservices-Diagramm will vollständig sein. Das nützliche ist bewusst unvollständig. Wähle die Frage, die das Diagramm beantwortet (wie eine Anfrage fließt, wo die asynchronen Grenzen liegen, welche Services welche Daten besitzen), und zeichne nur, was ihr dient. Vollständig, aber unlesbar hilft niemandem; fokussiert und klar ist der ganze Sinn.
Halte es lebendig
Microservices-Systeme ändern sich schneller als fast alles andere, was du diagrammieren würdest: neue Services, neue Events, ausgemusterte Abhängigkeiten. Eine handgezeichnete Version ist veraltet, bevor der Sprint endet. Leite das Gerüst aus der Quelle ab (Spezifikationen, Service-Manifeste oder ein Aufrufgraph), erzeuge es neu, wenn es sich weiterentwickelt, und behalte deine Gruppierung nach Grenzen und das Styling der Kanten als menschliche Schicht obendrauf. So hält das Diagramm mit einem System Schritt, dessen ganzes Versprechen ist, dass es sich unabhängig verändert.
Gruppiere nach Grenzen, style die Kanten danach, wie Services reden, zeig die Datenhoheit einmal und erzeuge die Basis, damit sie aktuell bleibt. Das ist ein Microservices-Diagramm, das klärt statt einzuschüchtern.