Blueprints
Blueprints sind strukturierte Ausgangspunkte für Teams, die schnelles Setup ohne Einbußen bei der Architekturklarheit wünschen. Anstatt jede Entität, jedes Attribut und jede Relation von Grund auf zu erstellen, startest Du mit einer bewährten Domain-Vorlage und passen sie an Deine spezifischen Anforderungen an.
Was ein Blueprint bietet
Ein Blueprint ist ein vollständiges, vorkonfiguriertes Mockomat-Projekt, das Folgendes enthält:
- Kohärente Basisentitäten — eine Reihe von Domain-Tabellen, die als logische Einheit zusammenarbeiten (z. B.
Product,Category,Reviewfür eine E-Commerce-Domain). - Initiale Relationsstrategie — Relationen zwischen Entitäten sind bereits mit korrekter Kardinalität und Richtung definiert.
- Attributkonfiguration — jede Entität kommt mit aussagekräftigen Attributen, Typen und Flags (sortierbar, filterbar, durchsuchbar), die bereits gesetzt sind.
- Datenzuordnungen — Felder sind vorab den passenden Datenquellen zugeordnet (echte Datensätze, Faker, Konstanten), sodass der Blueprint sofort in der Vorschau funktioniert.
- Starter-Operations-Erwartungen — API-Abfragenamen und Operations-Exposition sind für typische Anwendungsfälle konfiguriert.
- Sinnvolle Standardwerte — Paginierung, Sortierung und Filterung sind so konfiguriert, dass das Vorschauverhalten sofort nützlich ist.
Das Ergebnis ist ein Projekt, das Du innerhalb von Sekunden klonen und abfragen können — und dann in Deinem eigenen Tempo anpassen.
Blueprint-Galerie mit Kategorie- und Komplexitätsübersicht.
Verfügbare Blueprint-Kategorien
Blueprints decken gängige Domain-Muster ab, denen Teams häufig begegnen:
| Kategorie | Beispielentitäten | Typischer Anwendungsfall |
|---|---|---|
| E-Commerce | Product, Category, Order, Customer, Review | Online-Shops, Marktplätze, Produktkataloge |
| Blog / CMS | Post, Author, Category, Comment, Tag | Content-Plattformen, redaktionelle Workflows |
| CRM | Contact, Company, Deal, Activity, Pipeline | Vertriebsteams, Kundenbeziehungsmanagement |
| Projektmanagement | Project, Task, Team, Member, Sprint | Agile Workflows, Aufgabenverwaltungssysteme |
| SaaS / Subscription | Subscription, Plan, Invoice, Customer, Payment | SaaS-Abrechnung, Abonnementverwaltung |
| Inventar | Product, Warehouse, StockLevel, Supplier, Transfer | Lagerverwaltung, Lieferkette |
| HR / Personal | Employee, Department, Position, TimeEntry, Leave | HR-Systeme, Personalmanagement |
Jeder Blueprint wird von erfahrenen Architekten entworfen und auf strukturelle Qualität geprüft. Die Entitäten, Relationen und Namenskonventionen folgen Domain-Driven-Design-Prinzipien.
Blueprint-Kategoriekarten mit Entitätsanzahl und Komplexitätsindikator.
Wie Du einen Blueprint effektiv nutzt
1. Durchsuchen und auswählen
Öffne die Blueprint-Galerie und durchsuche nach Kategorie. Jede Blueprint-Karte zeigt:
- Die Domain-Kategorie
- Anzahl der enthaltenen Entitäten
- Eine kurze Beschreibung des abgedeckten Anwendungsfalls
- Komplexitätsindikator (einfach, moderat, umfassend)
Wähle den Blueprint, der Deiner Ziel-Domain am nächsten kommt. Er muss keine perfekte Übereinstimmung sein — Du wirst ihn in den nächsten Schritten anpassen.
2. In Deinen Workspace klonen
Klicke auf den Klon-Button, um eine Kopie des Blueprints in Deinem Workspace zu erstellen. Dies erstellt ein neues Projekt mit allen Entitäten, Attributen, Relationen und Zuordnungen des Blueprints. Der ursprüngliche Blueprint wird nicht verändert.
Was geklont wird:
- Alle Tabellen und ihre Attribute
- Alle Relationsdefinitionen
- Alle Datenzuordnungen (OFF_FIELD, FAKE, CONST)
- API-Konfiguration (Abfragenamen, Operations-Exposition)
- Paginierungs- und Sortierungsstandardwerte
Was nicht geklont wird:
- Der ursprüngliche Blueprint-Name (Du wählst einen neuen Projektnamen)
- Blueprint-spezifische Metadaten oder Badges
- Import-Job-Historie
3. Mit Deiner Geschäftssprache umbenennen
Ersetze die generischen Namen des Blueprints durch die tatsächliche Terminologie Deines Teams. Wenn der Blueprint Product verwendet, Deine Domain es aber Listing oder Item nennt, benenne es jetzt um. Konsistente Benennung von Anfang an verhindert spätere Verwirrung.
4. Attribute Tabelle für Tabelle überprüfen
Geh jede Entität durch und prüfst Du:
- Sind alle Attribute für Deine Domain relevant?
- Benötige zusätzliche Attribute, die im Blueprint nicht enthalten sind?
- Sind die Typen korrekt (string, number, boolean, date)?
- Sind die richtigen Felder als sortierbar, filterbar und durchsuchbar markiert?
Entferne Attribute, die Du nicht benötigst, und füge fehlende hinzu. Der Blueprint gibt Dir die Struktur — Du lieferst die Domain-Spezifika.
5. Über die Vorschau validieren
Führe eine Vorschauabfrage aus, um zu bestätigen, dass das geklonte und angepasste Modell korrekt funktioniert. Prüfe, dass:
- Datenzuordnungen realistische Werte erzeugen
- Relationen wie erwartet aufgelöst werden
- Filter und Sortierungen auf den konfigurierten Feldern funktionieren
- Die gesamte Antwortstruktur Deinen Frontend-Erwartungen entspricht
Blueprint-Klon-Ablauf in den aktiven Workspace.
Anpassungsstrategie
Schreibe nicht alles auf einmal um. Behalte das Blueprint-Skelett bei und entwickelst Du es in fokussierten Durchgängen weiter. Dieser Ansatz bewahrt die strukturelle Integrität und ermöglicht gleichzeitig progressive Verfeinerung.
Durchgang 1: Benennung und Kernattribute
Konzentriere Dich nur auf Umbenennung und Anpassung der wichtigsten Attribute:
- Entitäten umbenennen, damit sie zu Deiner Geschäftssprache passen
- Schlüsselattribute umbenennen (Bezeichner, Anzeigenamen, Primärwerte)
- 1–2 kritische Attribute pro Entität hinzufügen, die der Blueprint nicht enthält
- Attribute entfernen, die offensichtlich irrelevant sind
Nicht in diesem Durchgang Relationen, API-Konfiguration oder Zuordnungen anpassen.
Durchgang 2: Relationsbereinigung
Mit stabilisierten Namen überprüfen und passe Relationen an:
- Überprüfen, ob die Kardinalität für Deine Domain korrekt ist (1:1, 1:n, m:n)
- Richtung anpassen, wenn das Besitzmodell des Blueprints nicht zu Deinem passt
- Relationen hinzufügen, die der Blueprint nicht enthält
- Relationen entfernen, die nicht zutreffen
Führe nach diesem Durchgang eine Vorschau aus, um zu bestätigen, dass verschachtelte Abfragen weiterhin korrekt aufgelöst werden.
Durchgang 3: API-Expositions-Ausrichtung
Konfiguriere, welche Operationen verfügbar sind und wie sie benannt werden:
- Abfragen umbenennen, damit sie zu Deinen API-Konventionen passen
- Listen-/Detailoperationen pro Entität aktivieren oder deaktivieren
- Paginierungsstandardwerte anpassen
- Angemessene Filter- und Sortierkonfigurationen festlegen
Durchgang 4: Runtime-Validierung
Abschließender Validierungsdurchgang:
- Umfassende Abfragen gegen jede Entität ausführen
- Alle Filter und Sortierungen testen
- Relationsdurchquerung auf jeder Ebene verifizieren
- Alle verbleibenden Hinweise oder Warnungen beheben
Nach diesem Durchgang sollte Dein angepasster Blueprint produktionsreif für den Mock-API-Konsum sein.
Blueprint-Anpassung in Modell- und API-Ansichten.
Blueprint-Qualitätskriterien
Jeder Blueprint in der Galerie erfüllt Mindestqualitätsstandards:
- Mindestens 2 Entitäten mit aussagekräftigen Namen und Beschreibungen
- Mindestens 1 Relation, die Entitäten verbindet
- Vollständige Attributzuordnungen — keine nicht zugeordneten Felder
- Korrekte Namenskonventionen — PascalCase-Entitäten, camelCase-Attribute
- Keine Platzhalter- oder Zufallsnamen — alle Namen spiegeln echte Domain-Konzepte wider
- Funktionierende Vorschau — der Blueprint erzeugt sofort gültige Abfrageergebnisse
Diese Kriterien stellen sicher, dass jeder Blueprint sofort nützlich ist, nicht nur ein Gerüst.
Offizielle und Community-Blueprints
Blueprints gibt es in zwei Kategorien:
Offizielle Blueprints
Erstellt und gepflegt vom Mockomat-Team. Diese sind:
- Auf strukturelle Qualität und Namenskonventionen geprüft
- Mit neuen Features und Best Practices aktualisiert
- Mit einem „Offiziell"-Badge in der Galerie markiert
- Garantiert kompatibel mit der aktuellen Plattformversion
Community-Blueprints (In Kürze)
Von registrierten Nutzern veröffentlicht und mit der Community geteilt. Community-Blueprints:
- Durchlaufen ein automatisiertes Qualitäts-Review (Benennung, Struktur, Vollständigkeit)
- Werden vom Mockomat-Team moderiert
- Zeigen den Namen des Autors und die Klon-Anzahl
- Können bei außergewöhnlicher Qualität zu offiziellem Status befördert werden
Community-Blueprint-Einreichung und Review-Ablauf.