Editor öffnen

Abhängigkeitsgraph

Was von was abhängt, mit Fan-in-Zahlen und Zyklen, die ein Baum nicht zeigen kann.

1 Beispiel: Abhängigkeitsgraph

Abhängigkeiten der Frontend-Pakete

Sechs interne Pakete und ein externes, jedes mit Fan-in-Badge und einem sichtbaren Zyklus.

Ein Baum könnte das nicht zeigen: das Design-System hat mehrere Eltern, und zwei Pakete hängen voneinander ab. Fan-in-Badges zeigen, wo sich Abhängigkeiten sammeln, und die Rückkante ist der akzentuierte Zyklus.

Im Editor öffnen

Was ist ein Abhängigkeitsgraph?

Ein Abhängigkeitsgraph ist ein gerichteter Graph: Knoten sind Pakete, Services, Aufgaben oder Teams, ein Pfeil von A nach B heißt „A hängt von B ab“. Anders als ein Baum darf ein Knoten beliebig viele Abhängige haben.

Wichtig sind zwei Dinge: der Fan-in, also wie viele Knoten auf einen zeigen, und Zyklen. Ein Knoten mit hohem Fan-in ist ein Risiko, ein Zyklus verhindert eine saubere Reihenfolge. Ohne Zyklen spricht man von einem DAG.

Wann ein Abhängigkeitsgraph sinnvoll ist

  • Wenn du einen Monolithen aufteilst und sehen musst, welche Module sich gegenseitig importieren.
  • Wenn du die Upgrade-Reihenfolge von Bibliotheken oder die Startreihenfolge von Services festlegst.
  • Nicht, wenn jedes Element genau einen Elternknoten hat: Dann ist ein Baumdiagramm übersichtlicher.

So erstellst du einen guten Abhängigkeitsgraphen

  1. Lass alle Pfeile in eine Hauptrichtung zeigen, sodass Abhängigkeiten unten oder rechts liegen.
  2. Hebe Zyklen farblich hervor, denn sie sind fast immer der Grund für das Diagramm.
  3. Schreib den Fan-in an kritische Knoten.
  4. Fasse ab etwa 30 Knoten Pakete zu Gruppen zusammen.