Seminar Squidex – Content-Modellierung mit Schemas, Komponenten und Referenzen

Das Content-Modell bestimmt redaktionelle Bedienbarkeit, API-Stabilität und langfristige Änderbarkeit. Squidex-Schemas, Feldtypen, Komponenten, Referenzen, Validierungen und Lokalisierung müssen deshalb aus fachlichen Anwendungsfällen statt aus einzelnen Seitenlayouts abgeleitet werden.

Im Seminar entsteht ein versionierbares Domänenmodell für mehrere Ausgabekanäle. Modellierungsentscheidungen werden durch Redaktionstests, API-Abfragen und kontrollierte Schemaänderungen überprüft.

Zielgruppe

Content-Architekten, Backend- und Frontend-Entwickler, Product Owner, technische Redakteure und Informationsarchitekten

Voraussetzungen

Grundkenntnisse in Datenmodellierung, JSON und CMS-Konzepten; Erfahrung mit fachlichen Anforderungen und API-Verträgen ist hilfreich

Seminarziele

• Fachliche Begriffe und Anwendungsfälle in stabile Schemas überführen.
• Feldtypen, Validierungen und Lokalisierung passend auswählen.
• Komponenten und Referenzen ohne unnötige Kopplung modellieren.
• Schemaänderungen migrations- und rückwärtskompatibel planen.
• Content-Modelle mit Redaktions-, API- und Qualitätskriterien abnehmen.

Inhaltsübersicht

1. Zielgruppe und Voraussetzungen
2. Seminarziele
3. Domänenanalyse und Modellierungsziele
4. Schemas und Feldtypen entwerfen
5. Komponenten, Arrays und strukturierte Inhalte
6. Referenzen und Beziehungsmodelle
7. Lokalisierung und kanalübergreifende Varianten
8. Schema-Evolution, Migration und Modellabnahme
9. Praxisprojekt und Abnahme

1. Domänenanalyse und Modellierungsziele

Dieser Themenblock verbindet fachliche Entscheidung, konkrete Konfiguration und überprüfbare Abnahme. Die Schritte werden an einer durchgängigen Beispiel-App umgesetzt und mit geeigneten Positiv- und Negativfällen kontrolliert.

Schrittweises Vorgehen

1. Kanäle, Benutzerreisen, Inhalte und wiederverwendbare Begriffe inventarisieren.
2. Content-Typen von Darstellungsvarianten und Seitenkomponenten trennen.
3. Eigentümer, Lebenszyklus, Sprache und Schutzbedarf je Inhaltstyp erfassen.
4. API- und Redaktionserwartungen als prüfbare Akzeptanzkriterien formulieren.
5. Unklare Begriffe in einem verbindlichen Domänenglossar klären.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

2. Schemas und Feldtypen entwerfen

Der Abschnitt wird als vollständiger Arbeitsablauf bearbeitet: Ausgangslage erfassen, Zielzustand festlegen, Konfiguration umsetzen, Verhalten testen und die betriebliche beziehungsweise redaktionelle Übergabe dokumentieren.

Schrittweises Vorgehen

1. Für jeden Inhaltstyp ein eigenständiges Schema mit klarer Verantwortung anlegen.
2. Feldtypen nach Semantik, nicht nach momentaner UI-Darstellung auswählen.
3. Pflichtfelder, Wertebereiche, Muster und Eindeutigkeit gezielt konfigurieren.
4. Feldbezeichnungen und Hilfetexte redaktionell verständlich formulieren.
5. Schema mit repräsentativen gültigen und ungültigen Inhalten testen.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

3. Komponenten, Arrays und strukturierte Inhalte

Die Inhalte werden nicht isoliert demonstriert. Jede Entscheidung wird anhand von Auswirkungen auf Redaktion, API, Sicherheit, Betrieb und spätere Änderungen bewertet und anschließend praktisch validiert.

Schrittweises Vorgehen

1. Wiederkehrende Feldgruppen als Komponenten identifizieren.
2. Komponenten nur dort einsetzen, wo Struktur und Lebenszyklus gemeinsam bleiben.
3. Listen, Reihenfolgen und optionale Varianten mit realistischen Daten prüfen.
4. Tiefe Verschachtelung anhand von Redaktions- und API-Aufwand begrenzen.
5. Frontend-Mapping für jede Komponentenvariante dokumentieren.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

4. Referenzen und Beziehungsmodelle

Im Mittelpunkt steht ein reproduzierbares Vorgehen. Konfiguration, Testdaten, Prüfschritte und Abnahmekriterien werden so festgehalten, dass der Ablauf in einer eigenen Umgebung wiederholt werden kann.

Schrittweises Vorgehen

1. Eigenständige Entitäten von eingebetteten Strukturen unterscheiden.
2. Einzel- und Mehrfachreferenzen mit zulässigen Zielschema-Regeln konfigurieren.
3. Lösch-, Archivierungs- und Veröffentlichungsfolgen für referenzierte Inhalte definieren.
4. Zirkuläre, fehlende und unveröffentlichte Referenzen in Abnahmetests berücksichtigen.
5. Abfragekosten und Auflösungstiefe gegen alternative Modelle vergleichen.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

5. Lokalisierung und kanalübergreifende Varianten

Dieser Themenblock verbindet fachliche Entscheidung, konkrete Konfiguration und überprüfbare Abnahme. Die Schritte werden an einer durchgängigen Beispiel-App umgesetzt und mit geeigneten Positiv- und Negativfällen kontrolliert.

Schrittweises Vorgehen

1. Gemeinsame und lokalisierbare Felder je fachlicher Bedeutung festlegen.
2. Fallbacks und Mindestsprachen pro Veröffentlichungsfall definieren.
3. Kanalunterschiede über explizite Felder statt unstrukturierte Sonderwerte modellieren.
4. Redaktionelle Eingabemasken in mehreren Sprachen praktisch prüfen.
5. API-Antworten für vollständige und unvollständige Lokalisierungen testen.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

6. Schema-Evolution, Migration und Modellabnahme

Der Abschnitt wird als vollständiger Arbeitsablauf bearbeitet: Ausgangslage erfassen, Zielzustand festlegen, Konfiguration umsetzen, Verhalten testen und die betriebliche beziehungsweise redaktionelle Übergabe dokumentieren.

Schrittweises Vorgehen

1. Änderungen nach kompatibel, migrationspflichtig und fachlich brechend klassifizieren.
2. Neue Felder mit Default-, Nachpflege- oder Transformationsstrategie einführen.
3. Bestehende Inhalte vor und nach der Änderung automatisiert validieren.
4. Deprecation- und Abschaltplan für alte Felder dokumentieren.
5. Modell anhand von Redaktion, API, Performance und Governance formell abnehmen.

Prüfpunkte

• Die Konfiguration erfüllt den beschriebenen fachlichen Zweck ohne unnötige Sonderfälle.
• Berechtigungen, Fehlerzustände und Auswirkungen auf abhängige Komponenten sind geprüft.
• Ergebnis, offene Punkte und Wiederholungsweg sind nachvollziehbar dokumentiert.

Praxisprojekt und Abnahme

Aus einem fachlichen Anforderungskatalog entsteht ein mehrsprachiges, referenziertes und migrationsfähiges Content-Modell mit Abnahmetests.

Arbeitsschritte

1. Domänenbegriffe, Kanäle und Benutzerreisen analysieren.
2. Schemas, Felder, Komponenten und Referenzen modellieren.
3. Beispielinhalte in mehreren Sprachen erfassen und redaktionell testen.
4. REST- und GraphQL-Abfragen gegen das Modell prüfen.
5. Schemaänderung simulieren und Migrations- sowie Deprecation-Plan erstellen.

Abnahmekriterien

• Der fachliche Anwendungsfall ist mit repräsentativen Daten vollständig durchgespielt.
• Fehler-, Berechtigungs- und Wiederanlaufszenarien sind kontrolliert geprüft.
• Konfiguration, Tests und Verantwortlichkeiten sind so dokumentiert, dass der Transfer in eine eigene Umgebung möglich ist.