Dieser Post setzt den zweiundzwanzigsten Teil fort. In komplexen Modellen mit vielen Elementen wird include in Views schnell zur langen Liste. Tags lösen das: Elemente bekommen semantische Labels, Views filtern nach diesen Labels.

Tags in der Specification definieren

Tags werden in specification.tags definiert — mit optionalem Style für draw.io:

{
  "specification": {
    "tags": [
      {
        "id":          "team-backend",
        "description": "Elemente des Backend-Teams"
      },
      {
        "id":          "team-frontend",
        "description": "Elemente des Frontend-Teams"
      },
      {
        "id":          "external",
        "description": "Externe Systeme und Drittanbieter",
        "style": {
          "fillColor": "#dae8fc",
          "strokeColor": "#6c8ebf"
        }
      },
      {
        "id":          "critical",
        "description": "Kritische Systeme im Zahlungspfad",
        "style": {
          "fillColor": "#ffe6cc",
          "strokeColor": "#d6b656"
        }
      },
      {
        "id":          "gdpr",
        "description": "Verarbeitet personenbezogene Daten"
      }
    ]
  }
}

Das style-Feld überschreibt die draw.io-Farben für alle Elemente mit diesem Tag — ein visuelles Team-Coding direkt aus der Spezifikation.

Elemente taggen

Tags werden als Array im Element gesetzt:

{
  "model": {
    "authservice": {
      "kind": "service",
      "title": "Auth Service",
      "tags": ["team-backend", "critical", "gdpr"]
    },
    "shop-frontend": {
      "kind": "frontend",
      "title": "Shop Frontend",
      "tags": ["team-frontend"]
    },
    "stripe": {
      "kind": "external",
      "title": "Stripe",
      "tags": ["external", "critical"]
    },
    "shop-api": {
      "kind": "service",
      "title": "Shop API",
      "tags": ["team-backend", "critical"]
    }
  }
}

bausteinsicht validate prüft dass alle verwendeten Tag-IDs in specification.tags definiert sind.

Views mit Tags filtern

Statt include mit expliziten Element-IDs können Views Tags als Filter nutzen:

filter-tags: Nur Elemente MIT diesen Tags

{
  "views": {
    "backend-team-view": {
      "title": "Backend-Team Architektur",
      "filter-tags": ["team-backend"]
    },
    "critical-payment-path": {
      "title": "Kritischer Zahlungspfad",
      "filter-tags": ["critical"]
    },
    "gdpr-scope": {
      "title": "DSGVO-relevante Elemente",
      "filter-tags": ["gdpr"]
    }
  }
}

filter-tags verwendet AND-Semantik bei mehreren Tags:

{
  "critical-backend": {
    "title": "Kritische Backend-Services",
    "filter-tags": ["team-backend", "critical"]
  }
}

exclude-tags: Elemente OHNE diese Tags

{
  "internal-only": {
    "title": "Interne Systeme",
    "exclude-tags": ["external"]
  }
}

Kombiniert mit include und scope

Tags-Filter können mit include, scope und exclude kombiniert werden:

{
  "shop-backend-detail": {
    "title": "Shop Backend Detail",
    "scope": "shop",
    "filter-tags": ["team-backend"],
    "exclude-tags": ["archived"]
  }
}

Diese View zeigt: Elemente unter shop.* die team-backend haben aber nicht archived sind.

Tags als Cross-Cutting Concerns

Tags eignen sich besonders für Querschnittsthemen die sich über Team- und Systemgrenzen ziehen:

TagTypische Verwendung

gdpr

Datenschutz-Review: alle datenverarbeitenden Elemente auf einen Blick

critical

Incident-Response: sofort sehen welche Systeme zum kritischen Pfad gehören

team-X

Team-spezifische Views ohne manuelle Pflege der include-Listen

deprecated

Ablösungs-Planung: alle veralteten Elemente gezielt anzeigen

Tags in specification.tags müssen explizit definiert werden — validate lehnt unbekannte Tag-IDs in Elementen ab. Das verhindert Tippfehler und hält die Tag-Liste konsistent.

Tags im Exportformat

Beim Export (→ Teil 6) werden Tags in der Tabellen-Ausgabe mitgeführt:

bausteinsicht export-table --format csv
# → id, kind, title, technology, tags, status, ...

So lassen sich DSGVO-Audits, Team-Inventare oder Security-Reviews direkt aus dem Modell als CSV generieren.

Beispiel-Modell

Das Beispiel für diesen Teil (Tags mit Styles, filter-tags und exclude-tags in Views) liegt unter teil_23.jsonc.

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

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

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

backend
context
critical

Generierte PlantUML-Diagramme via bausteinsicht export-diagram (Context View mit externen Systemen):

Diagram
Diagram
Diagram

Weiter geht es mit CI/CD

Tags und Filterung sind mächtig — aber ein Modell das nur lokal validiert wird, ist erst halb abgesichert. Im nächsten Teil geht es darum wie validate, diff und export in GitHub Actions eingebunden werden: automatische Prüfung als Build-Gate, Modell-Diff im Pull Request und SVG-Export nach jedem Push.

Offizielle Dokumentation: User Manual · Tutorial auf doctoolchain.org