Teil 28: Performance bei großen Modellen — Scoping, Partial Views und Subsysteme

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: Elementanzahl Symptom Lösung 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 Situation Empfehlung Ein Team, ein System, 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: Generierte PlantUML-Diagramme via bausteinsicht export-diagram (Order-Flow View): Was als nächstes kommt Teil 29: Real-Life-Beispiel — das Big Bank Example von Simon Brown (Structurizr) vollständig nach Bausteinsicht JSONC transformiert 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: Neu starten? → Teil 2: Getting Started Architekturregeln? → Teil 8: Validation & Linting Mit KI arbeiten? → Teil 10: LLM/AI Workflows Team-Architektur? → Teil 16: Workspace In CI/CD einbinden? → Teil 24: CI/CD Integration Von anderen Tools? → Teil 25: Migration Offizielle Dokumentation: User Manual · Tutorial auf doctoolchain.org