Enterprise
Die Enterprise-Dokumentation konzentriert sich auf Kontrolle, Governance und wiederholbare Architekturentwicklung. Mockomat Enterprise ist für Organisationen konzipiert, die maximale Isolation, Compliance-Fähigkeiten und die Möglichkeit benötigen, Domain-Modellierung über mehrere Teams hinweg zu skalieren.
Enterprise-Prioritäten
Enterprise-Teams arbeiten unter anderen Bedingungen als einzelne Entwickler oder kleine Teams. Die wichtigsten Prioritäten sind:
- Isolation und klare Grenzen — strikte Trennung zwischen Mandanten, Projekten und Daten.
- Kontrollierte API-Exposition — private Endpunkte mit authentifiziertem Zugang für jeden Konsumenten.
- Reproduzierbare Architekturzustände — die Fähigkeit, jeden Modellzustand zu jedem Zeitpunkt nachzubilden oder zu auditieren.
- Nachvollziehbarer Änderungsfluss — Transparenz darüber, wer was, wann und warum geändert hat.
- Compliance-Bereitschaft — Datenhandhabungspraktiken, die regulatorische Anforderungen erfüllen.
Mandanten- und Runtime-Isolationsmodell-Übersicht.
Mandantenisolation
Jeder Enterprise-Kunde operiert innerhalb eines dedizierten Mandanten, der strikte Grenzen auf jeder Ebene des Systems bietet.
Datenisolation
- Separate MongoDB-Sammlungen — die Mock-Daten jedes Mandanten werden in isolierten Sammlungen gespeichert, nie mit anderen Mandanten vermischt.
- Mandantenbezogene Abfragen — jede Datenbankabfrage wird automatisch nach Mandanten-ID gefiltert, um mandantenübergreifende Datenlecks zu verhindern.
- Unabhängige Projekträume — Projekte innerhalb eines Mandanten teilen keine Daten oder Konfiguration mit Projekten in anderen Mandanten.
Runtime-Isolation
- Mandantenspezifische Schemagenerierung — GraphQL-Schemas werden unabhängig pro Projekt innerhalb des Mandanten generiert.
- Isolierte API-Endpunkte — jedes Projekt erhält seinen eigenen Endpunktpfad, begrenzt auf die Zugriffskontrollen des Mandanten.
- Unabhängige Ratenbegrenzung — Anfragelimits und Drosselung werden pro Mandant konfiguriert, nicht global geteilt.
Konfigurationsisolation
- Individuelle Sitzungslimits — Enterprise-Mandanten können ihre eigenen gleichzeitigen Sitzungs- und API-Actor-Limits festlegen.
- Individuelle Inaktivitäts-Timeouts — Sitzungs- und Actor-Inaktivitäts-Timeout-Werte sind pro Mandant konfigurierbar.
- Individuelle Ratenbegrenzung — Anfrage-Ratenlimits können an die Nutzungsmuster der Organisation angepasst werden.
Daten-, Runtime- und Konfigurationsisolationsschichten.
Governance-Modell
Ein praktischer Governance-Ansatz stellt sicher, dass Domain-Modellierung konsistent und hochwertig bleibt, wenn die Organisation skaliert.
Domain-Ownership
Weise klare Verantwortung für jeden Geschäftsdomänenbereich zu:
- Domain-Owner — verantwortlich für Entitätsbenennung, Attributdefinitionen und Relationsstrategie innerhalb ihrer Domain.
- Reviewer — Teammitglieder, die Änderungen validieren, bevor sie für den Produktionseinsatz freigegeben werden.
- Konsumenten — Frontend-Entwickler und Integratoren, die die Mock-API abfragen, aber das Modell nicht ändern.
Gemeinsame Namenskonventionen
Definiere organisationsweite Standards für:
- Entitätsbenennung — PascalCase, Singular-Substantive, Geschäftssprache (z. B.
Customerstattcustomers_tbl) - Attributbenennung — camelCase, beschreibend, keine Abkürzungen (z. B.
totalAmountstatttot_amt) - Relationsbenennung — klare Richtungs- und Kardinalitätsindikatoren
- Abfragebenennung — konsistente Pluralisierung für Listenabfragen, Singular für Detailabfragen
Dokumentiere diese Konventionen und verteile sie über interne Blueprints, damit jedes Team mit denselben Standards startet.
Review-Gates
Etabliere Review-Checkpoints an wichtigen Phasen:
| Phase | Review-Fokus | Wer prüft |
|---|---|---|
| Modelländerung | Namenskonsistenz, Attributvollständigkeit, Relationskorrektheit | Domain-Owner |
| API-Expositionsänderung | Operations-Oberfläche, Abfragebenennung, Paginierungsstandards | Domain-Owner + Integrator |
| Vor-Export-Validierung | Runtime-Verhalten, Filter-/Sortierkorrektheit, Relationsdurchquerung | Domain-Owner + QA |
| Nach-Export-Review | Generierte Codequalität, Modulgrenzen, DTO-Abdeckung | Entwicklungsteamleiter |
Runtime-Validierungskriterien
Definiere, was „bereit" für jede Entität bedeutet, bevor sie freigegeben werden kann:
- Alle Pflichtattribute haben stabile, nicht-null Werte
- Alle Relationen werden in der Vorschau korrekt aufgelöst
- Filter- und Sortieroperationen funktionieren auf allen konfigurierten Feldern
- Paginierung erzeugt saubere Seitengrenzen
- Keine ungelösten Hinweise oder Warnungen verbleiben
Governance-Kontrollen über Modellierungs- und Runtime-Phasen.
Team-Zusammenarbeit
Enterprise-Tarife unterstützen Multi-User-Teams mit rollenbasierter Zugriffskontrolle.
Benutzerrollen
| Rolle | Fähigkeiten |
|---|---|
| Admin | Voller Zugang: Projekte erstellen/löschen, Teammitglieder verwalten, Mandanteneinstellungen konfigurieren |
| User Admin | Teammitglieder verwalten, Rollen zuweisen, Audit-Logs einsehen |
| User | Projekte erstellen und bearbeiten, Vorschau ausführen, Backends exportieren |
| Guest | Nur-Lesen-Zugriff auf freigegebene Projekte und Vorschau |
Gleichzeitige Sitzungsverwaltung
Enterprise-Mandanten unterstützen bis zu 50+ gleichzeitige Sitzungen (konfigurierbar). Jede authentifizierte Browser-Sitzung zählt zum Limit.
Sitzungsverhalten:
- Sitzungen werden in Redis mit konfigurierbaren Inaktivitäts-Timeouts verfolgt.
- Wenn eine Sitzung über den Timeout-Zeitraum hinaus inaktiv ist, wird sie automatisch freigegeben.
- Wenn das Sitzungslimit erreicht ist, werden neue Anmeldeversuche blockiert, bis eine Sitzung verfügbar wird.
- Admins können aktive Sitzungen einsehen und verwalten.
API-Actor-Limits
Für externen API-Konsum können Enterprise-Mandanten gleichzeitige Actor-Limits pro API-Schlüssel konfigurieren:
- Standard: 20 gleichzeitige Actors pro Mandant
- Pro API-Schlüssel: Konfigurierbare Limits pro Schlüssel für verschiedene Konsumenten oder Umgebungen
- Actor-Tokens: Jeder externe Konsument erhält ein zeitlich begrenztes Actor-Token, das zum Parallelitätslimit zählt
- Automatische Bereinigung: Abgelaufene Actor-Tokens werden automatisch freigegeben
Teammitglieder-Verwaltung und Rollenzuweisung.
Eigene Datensätze
Enterprise-Kunden können proprietäre Datensätze zusammen mit den eingebauten Datenquellen von Mockomat hochladen und verwenden.
Upload und Zuordnung
- Daten hochladen — stelle Deinen Datensatz in einem unterstützten Format bereit (CSV, JSON).
- Metadaten-Extraktion — Mockomat scannt den Datensatz und generiert Metadaten (Feldnamen, Typen, Beispielwerte).
- Zu Attributen zuordnen — verwende die hochgeladenen Daten als Zuordnungsquelle (genau wie OFF_FIELD) für jedes Attribut in Deinem Modell.
- Isolierte Speicherung — eigene Datensätze werden in mandantenisolierten Sammlungen gespeichert, nie mit anderen Mandanten geteilt.
Anwendungsfälle
- Branchenspezifische Daten — verwendest Du echte Produktkataloge, Mitarbeiterverzeichnisse oder Bestandsdaten für realistischere Mock-APIs.
- Compliance-Tests — teste mit Daten, die der Form Deines Produktionsschemas entsprechen, ohne echte Produktionsdaten zu verwenden.
- Demo-Vorbereitung — erstellst Du Mock-APIs mit gebrandeten, realistischen Daten für Kundenpräsentationen.
Eigener Datensatz-Upload und Zuordnungs-Workflow.
Sicherheit und Compliance
Enterprise-Tarife umfassen erweiterte Sicherheitsfunktionen für Organisationen mit strengen Compliance-Anforderungen.
Authentifizierung
- JWT-Authentifizierung — jeder Zugriff auf die Management-API erfordert gültige JWT-Tokens.
- API-Schlüssel-Authentifizierung — externe Konsumenten authentifizieren sich mit projektbezogenen API-Schlüsseln.
- Actor-Tokens — zeitlich begrenzte Tokens für das Management gleichzeitiger API-Konsumenten.
- SSO/SAML-Integration — geplant für Organisationen, die zentralisiertes Identitätsmanagement benötigen.
Zugriffskontrolle
- Rollenbasierter Zugriff — granulare Berechtigungen basierend auf Benutzerrolle (Admin, User Admin, User, Guest).
- Berechtigungen auf Projektebene — steuern, wer auf bestimmte Projekte zugreifen, sie bearbeiten oder exportieren kann.
- Isolation auf Mandantenebene — jeder Zugriff ist automatisch auf die Mandantengrenze beschränkt.
Datenschutz
- Keine Produktionsdaten erforderlich — Mock-APIs verwenden synthetische oder datensatzgestützte Daten, niemals echte Kundeninformationen.
- Mandantenisolierte Speicherung — die Daten jedes Mandanten werden separat gespeichert und sind für andere Mandanten nicht zugänglich.
- Verschlüsselte Kommunikation — jeglicher API-Traffic verwendet HTTPS.
- Audit-Logging — Zugriffsmuster, Modelländerungen und Export-Ereignisse nachverfolgen (geplant).
Compliance-Aspekte
- DSGVO-Bereitschaft — synthetische Daten eliminieren PII-Bedenken in Entwicklungsumgebungen.
- Datenresidenz — On-Premise-Deployment-Option für Organisationen mit Datensouveränitätsanforderungen.
- Aufbewahrungsrichtlinien — konfigurierbare Datenaufbewahrung für Sitzungs- und Nutzungsdaten.
Enterprise-Sicherheits- und Compliance-Feature-Übersicht.
On-Premise-Deployment
Für Organisationen, die vollständige Kontrolle über ihre Daten und Infrastruktur benötigen, bietet Mockomat eine On-Premise-Deployment-Option.
Was Du erhältst:
- Eine selbst gehostete Mockomat-Instanz auf Deiner eigenen Infrastruktur
- Volle Datensouveränität — alle Daten bleiben innerhalb Deines Netzwerks
- Individuelle Domain- und SSL-Konfiguration
- Integration mit Deinen bestehenden Authentifizierungssystemen
- Direkter Datenbankzugriff für fortgeschrittene Anwendungsfälle
Anforderungen:
- Docker-kompatible Hosting-Umgebung
- MongoDB-, MariaDB- und Redis-Instanzen (können Managed Services oder selbst gehostet sein)
- Node.js-Runtime (v20+)
Preisgestaltung: 1.000 $ Setup + 199 $/Monat Wartung (inklusive Updates und Support).
Runtime- und operative Erwartungen
Enterprise-Teams sollten Runtime-Verhalten als explizite Qualitätsoberfläche mit messbaren Standards behandeln.
Was zu erwarten ist
- Deterministisch genug für Zusammenarbeit — dieselbe Abfrage erzeugt jedes Mal dieselbe strukturelle Form, sodass Teammitglieder sich auf konsistentes Verhalten verlassen können.
- Transparent genug für Reviews — jede Runtime-Entscheidung (Filterauflösung, Relations-Lookup, Sortierreihenfolge) ist auf die Modellkonfiguration zurückführbar.
- Flexibel genug für kontrollierte Iteration — Modelle können sich weiterentwickeln, ohne bestehende Konsumenten zu brechen, solange Änderungen zuerst über die Vorschau validiert werden.
Operative Best Practices
- Validierungskriterien pro Entität definieren, bevor sie einem Team zugewiesen wird.
- Runtime-Prüfungen in Review-Prozesse einbeziehen — Vorschau-Validierung als verpflichtenden Schritt behandeln.
- Modell-Exporte versionieren — eine Historie generierter Backends führen, die an Modell-Snapshots gebunden ist.
- API-Nutzung überwachen — Anfragemuster, Fehlerraten und Antwortzeiten über Endpunkte hinweg verfolgen.
- Einen Update-Rhythmus etablieren — regelmäßige Modell-Reviews planen, um Domain-Definitionen an sich entwickelnde Geschäftsanforderungen anzupassen.
Enterprise-Runtime-Validierung und operative Checkpoints.