Enterprise

Enterprise ist der Tarif für Organisationen, die über Business hinauswachsen: mehr Teammitglieder, keine Katalog-Limits für Projekte und Anfragen und Limits, die an Deinen Vertrag angepasst werden können. Diese Seite erklärt, was der Tarif enthält, wie Mockomat Dein Konto von anderen trennt und wie Du die Domain-Modellierung über mehrere Teams hinweg konsistent hältst.

Enterprise erhalten

Enterprise wird mit unserem Vertrieb vereinbart, nicht online gekauft. Nutze Mit dem Vertrieb sprechen in der App oder das Kontaktformular; der Preis ist auf Anfrage.

Was Enterprise enthält

• Alles aus Business: API-Schlüssel, Team-Rollen, Code-Export, Endpunkt-Analytik.
• Keine Katalog-Limits für Projekte, Workspaces, monatliche API-Anfragen, API-Schlüssel pro Projekt, Tabellen, Attribute, Relationen, Operationen und Board-Notizen.
• Bis zu 26 Teammitglieder, davon 5 Verwalter.
• Das Enterprise-Code-Paket: Der Code-Export erzeugt ein NestJS-Backend und ein Angular-Frontend (siehe Export).
• An Deinen Vertrag angepasste Limits: Unser Team stellt die Limits Deines Kontos auf das ein, was Du mit dem Vertrieb vereinbart hast.

Die Limits der anderen Tarife findest Du unter Konto und Tarife.

ent-01-tenant-isolationMissing

Übersicht über das Konto- und Projektzugriffsmodell.

Wie Dein Konto getrennt ist

Enterprise nutzt dieselbe Plattform wie jeder andere Tarif. Diese Grenzen gelten für jedes Konto:

• Dein Konto ist die Grenze. Projekte, Modelle, Mitglieder, API-Schlüssel und Tarif-Limits gehören zu Deinem Konto. Jede Anfrage wird dagegen geprüft, sodass Mitglieder anderer Konten Deine Projekte nicht öffnen können.
• Projektzugriff pro Mitglied. Verwalter sehen jedes Projekt des Kontos. Andere Mitglieder sehen die Projekte, für die sie bei der Einladung Zugriff erhalten haben, optional mit einer Überschreibung pro Projekt, die ihre Rolle einschränken, aber nie erhöhen kann.
• Ein API-Schlüssel pro Konsument. Jedes Projekt eines Kontos beantwortet seine Mock-API nur Anfragen mit einem API-Schlüssel dieses Projekts. Schlüssel lassen sich jederzeit widerrufen.
• Gemeinsame, schreibgeschützte Mock-Daten. Die Mock-API liefert Zeilen aus dem Datenpool von Mockomat, den unser Team importiert und pflegt. Deine Anfragen lesen ihn nur, und er ist in jedem Tarif derselbe. Eigene Datensätze kannst Du nicht hochladen.

ent-01b-isolation-architectureMissing

Grenzen von Konto, Projekten und Daten.

Team und Rollen

Rolle	Was sie hinzufügt
Nur Lesen	Sieht Projekte, das Modell und die Datenvorschau; liest Board-Notizen
Reporter	Schreibt und bearbeitet Board-Notizen und ihre Kommentare
Bearbeiter	Baut das Modell, legt Projekte an, verwaltet API-Schlüssel, führt den Code-Export aus
Verwalter	Löscht Projekte, verwaltet Mitglieder und ihren Projektzugriff, verwaltet Workspaces

Jede Rolle umfasst alles der Rollen darüber. Der Eigentümer des Kontos ist Verwalter und für die Abrechnung zuständig. Die vollständige Berechtigungsliste und den Einladungsablauf findest Du unter Team & Roles (Englisch).

ent-02b-team-collaborationMissing

Teammitglieder-Verwaltung und Rollenzuweisung.

Sitzungen und externe Konsumenten

• Anmelde-Sitzungen: Bei Enterprise kann der Eigentümer des Kontos auf mehreren Geräten gleichzeitig angemeldet bleiben. Eingeladene Mitglieder erhalten das nicht über das Konto, dem sie beitreten: Sie können nur an einer Stelle gleichzeitig angemeldet sein, es sei denn, sie besitzen selbst ein Konto, dessen Tarif mehr erlaubt; eine Anmeldung an anderer Stelle beendet ihre frühere Sitzung. Alle werden nach einer Zeit ohne Aktivität automatisch abgemeldet.
• API-Konsumenten: Jede Anfrage an die Mock-API trägt einen API-Schlüssel des Projekts. Nutze einen Schlüssel pro Konsument oder Umgebung (Entwicklung, Staging, CI), damit Du einen widerrufen kannst, ohne die anderen zu berühren.
• Actor-Tokens (optional): Ein Konsument kann ein Actor-Token anfordern, damit die gleichzeitige Nutzung eines API-Schlüssels begrenzt werden kann. Siehe Abschnitt „Actor-Tokens“ unter Integratoren.

Governance-Modell

Ein praktischer Governance-Ansatz hält die Domain-Modellierung konsistent, wenn weitere Teams dazukommen.

Domain-Ownership

Weise jedem Geschäftsbereich klare Verantwortung zu:

• Domain-Owner — verantwortlich für Entitätsbenennung, Attributdefinitionen und Relationsstrategie in der eigenen Domain.
• Reviewer — Teammitglieder, die Änderungen prüfen, bevor sich Konsumenten darauf verlassen (dazu passt die Rolle Reporter).
• Konsumenten — Frontend-Entwickler und Integratoren, die die Mock-API abfragen, aber das Modell nicht ändern (dazu passt die Rolle Nur Lesen).

Gemeinsame Namenskonventionen

Lege organisationsweite Standards fest für:

• Entitätsbenennung — PascalCase, Substantive im Singular, Geschäftssprache (z. B. Customer, nicht customers_tbl)
• Attributbenennung — camelCase, beschreibend, ohne Abkürzungen (z. B. totalAmount, nicht tot_amt)
• Relationsbenennung — klare Richtung und Kardinalität
• Operationsbenennung — einheitliche Pluralnamen für Listenoperationen, Singularnamen für Detailoperationen

Pflege ein Referenzprojekt, das diesen Konventionen folgt, und kopiere es mit Projekt kopieren als Ausgangspunkt für neue Projekte.

Review-Gates

Phase	Review-Fokus	Wer prüft
Modelländerung	Namenskonsistenz, Vollständigkeit der Attribute, Korrektheit der Relationen	Domain-Owner
Änderung der API-Exposition	Operationen, Parameter, Seitengrößen	Domain-Owner + Integrator
Vor dem Export	Runtime-Verhalten, Parameter, Sortierung, Relationen	Domain-Owner + QA
Nach dem Export	Generierter Code, Modulgrenzen, Eingaben	Leitung des Entwicklungsteams

Bereitschaftskriterien

Lege fest, was „bereit“ für jede Entität bedeutet, bevor Konsumenten sich darauf verlassen:

• Jedes Attribut, das Konsumenten brauchen, ist an eine Spalte der importierten Daten gebunden
• Relationen werden in der Vorschau aufgelöst
• Operationsparameter und Sortierung liefern die erwarteten Zeilen
• Die Paginierung erzeugt saubere Seitengrenzen

ent-02-governance-controlsMissing

Governance-Kontrollen über Modellierungs- und Runtime-Phasen.

Sicherheit

• Anmeldung: Die App nutzt pro Anmelde-Sitzung ein signiertes Token. Abmelden, Inaktivität und eine Passwortänderung beenden Sitzungen auf dem Server.
• API-Schlüssel: Schlüssel sind Geheimnisse. Nutze sie aus serverseitigem Code, aus CI oder über einen Proxy — liefere nie einen Schlüssel in einem Frontend-Bundle aus — und widerrufe einen Schlüssel, sobald er nicht mehr gebraucht wird.
• Verschlüsselter Datenverkehr: Die App und die Mock-API werden über HTTPS ausgeliefert.
• Keine Produktionsdaten nötig: Mock-APIs liefern Zeilen aus dem Datenpool von Mockomat, sodass Deine Testumgebungen nie echte Kundendaten brauchen.

ent-03c-security-overviewMissing

Sicherheitsübersicht.

Operative Best Practices

1. Lege Bereitschaftskriterien pro Entität fest, bevor Du sie einem Team zuweist.
2. Nimm Runtime-Prüfungen in Reviews auf — führe die Vorschau aus, bevor Konsumenten sich auf eine Änderung verlassen.
3. Exportiere an Meilensteinen — halte den generierten Code in der Versionsverwaltung und vermerke, aus welchem Modellstand er stammt.
4. Beobachte die Nutzung — sieh in der Endpunkt-Analytik nach, welche Operationen Konsumenten aufrufen, bevor Du sie änderst.
5. Prüfe regelmäßig — halte Domain-Definitionen im Einklang mit sich ändernden Geschäftsanforderungen.

ent-03-enterprise-runtimeMissing

Enterprise-Runtime-Validierung und operative Checkpoints.

Enterprise-Implementierungshinweis

Enterprise User

Starte mit einem kleinen Pilot — eine Domain, ein Team — mit klarer Verantwortung und festem Review-Rhythmus. Erweitere die Konventionen, wenn weitere Teams dazukommen.

Integrator-Hinweis für Enterprise-Kontexte

Developer / Integrator

Nutze einen API-Schlüssel pro Umgebung (Entwicklung, Staging, CI) und prüfe das Runtime-Verhalten in CI, bevor Du Dich auf eine Modelländerung verlässt.