Dieser Post setzt den siebenundzwanzigsten Teil fort. Ein Modell mit 10 Elementen ist einfach. Bei 50+ Elementen stellt sich die Frage: was sieht wer, wann, in welcher View? Und ab wann wird sync und draw.io langsam?

Wann wird ein Modell "groß"?

Praktische Grenzwerte:

ElementanzahlSymptomLösung

< 30

Alles in einer View zeigbar

Eine Hauptview reicht

30–80

Eine View wird unlesbar — zu viele Shapes

Mehrere fokussierte Views, scope + include

80–200

sync braucht Sekunden, draw.io ruckelt

Views gezielt klein halten, Workspace prüfen

> 200

draw.io mit einer Page mit 200+ Shapes ist nicht mehr nutzbar

Workspace mit separaten Modellen (→ Teil 16)

Views klein halten: scope und include

Das wirksamste Mittel gegen große Views ist konsequentes Scoping.

Schlechte View:

{
  "views": {
    "everything": {
      "title": "Gesamtsystem",
      "include": ["*"]
    }
  }
}

Besser: fokussierte Views:

{
  "views": {
    "system-context": {
      "title": "System Context",
      "scope": "shop",
      "include": ["shop", "payment", "user"]
    },
    "backend-containers": {
      "title": "Backend Container",
      "scope": "shop",
      "include": ["shop.api", "shop.db", "shop.cache", "shop.queue"]
    },
    "payment-flow": {
      "title": "Zahlungsfluss",
      "filter-tags": ["payment-path"]
    }
  }
}

Faustregel: eine View sollte maximal 15–20 Elemente zeigen. Mehr als das ist für Menschen nicht mehr auf einen Blick erfassbar.

Relationship Lifting als Feature nutzen

Relationship Lifting (→ Teil 3) hebt Beziehungen automatisch auf das nächste sichtbare Elternelement an. Das bedeutet: in einer abstrakten View (nur shop und payment) werden alle internen Beziehungen zwischen shop. und payment. automatisch als eine Verbindung zwischen shop und payment dargestellt.

Man muss also keine separaten Beziehungen für verschiedene Abstraktionsebenen definieren — das Lifting erledigt das automatisch.

{
  "relationships": [
    { "from": "shop.checkout-service", "to": "payment.stripe-adapter", "kind": "calls" },
    { "from": "shop.order-service",    "to": "payment.stripe-adapter", "kind": "calls" }
  ]
}

Tags als dynamisches Scoping

Statt jede View mit expliziten IDs zu pflegen, können Tags als dynamischer Filter verwendet werden (→ Teil 23).

Das skaliert besonders gut: wenn ein neues Element mit "tags": ["payment-path"] hinzugefügt wird, erscheint es automatisch in allen Views mit "filter-tags": ["payment-path"] — ohne die View-Definition anzufassen.

{
  "views": {
    "critical-path": {
      "title": "Kritischer Zahlungspfad",
      "filter-tags": ["payment-path"]
    },
    "team-backend": {
      "title": "Backend-Team View",
      "filter-tags": ["team-backend"],
      "exclude-tags": ["archived"]
    }
  }
}

draw.io Performance: Ursachen und Gegenmittel

draw.io wird träge wenn eine Page zu viele Shapes hat. Konkrete Maßnahmen:

Shapes reduzieren: * Hierarchische Elemente (container: true) zusammenklappen — draw.io zeigt nur das Container-Shape, nicht die Kinder * Views aufteilen statt eine große Page zu haben

draw.io-Datei bereinigen:

# draw.io-Datei enthält manchmal veraltete Shapes aus gelöschten Views
# Sync bereinigt das:
bausteinsicht sync
# Danach draw.io neu laden — veraltete Shapes wurden entfernt

Separate draw.io-Dateien per View: Aktuell speichert Bausteinsicht alle Views als Pages in einer .drawio-Datei. Bei sehr vielen Views (20+) kann es helfen die Views in Gruppen aufzuteilen — das ist aber eine manuelle Entscheidung.

Wann Workspace die richtige Lösung ist

Das Workspace-Feature (Teil 16) ist die Lösung wenn:

  • Das System aus wirklich unabhängigen Subsystemen besteht die von verschiedenen Teams verantwortet werden

  • Ein einzelnes JSONC-Modell über 200 Elemente wächst

  • Teams wollen ihr Modell ohne Koordination mit anderen ändern können

Der Workspace erlaubt separate Modelle mit Cross-Referenzen:

{
  "workspace": {
    "models": {
      "shop":     { "path": "shop/architecture.jsonc",     "prefix": "shop" },
      "payment":  { "path": "payment/architecture.jsonc",  "prefix": "pay" },
      "infra":    { "path": "infra/architecture.jsonc",    "prefix": "inf" }
    }
  }
}

Jedes Team pflegt sein Modell unabhängig. Im Workspace-Kontext können Views Elemente aus mehreren Modellen kombinieren.

Entscheidungshilfe: wann was

SituationEmpfehlung

Ein Team, ein System, < 100 Elemente

Fokussierte Views, Tags-Filter, scope

Mehrere Teams, ein System, 100–200 Elemente

Ownership-Conventions, Workspace prüfen

Mehrere Teams, mehrere unabhängige Systeme

Workspace mit separaten Modellen

Draw.io träge, Modell noch klein

Views aufteilen, überflüssige Shapes entfernen, sync neu ausführen

Validate dauert > 5 Sekunden

Bekanntes Performance-Problem — als Issue melden

Beispiel-Modell

Das Beispiel für diesen Teil (größeres Modell mit Gateway, Microservices, Event Bus) liegt unter teil_28.jsonc.

So sieht das Ergebnis in draw.io aus (bausteinsicht sync):

Das draw.io-File dafür findest du hier: teil_28.drawio

Generierte PNG-Dateien via bausteinsicht export --image-format png:

context
gateway
order-flow

Generierte PlantUML-Diagramme via bausteinsicht export-diagram (Order-Flow View):

Diagram
Diagram
Diagram

Was als nächstes kommt

Das war die erweiterte Tutorial-Serie

Mit Teil 28 schließt die Bausteinsicht-Tutorial-Serie — von der Projektvorstellung in Teil 1 bis zu Performance und Skalierung in Teil 28.

Die wichtigsten Einstiegspunkte für schnelles Nachschlagen:

Offizielle Dokumentation: User Manual · Tutorial auf doctoolchain.org