Enterprise

La documentazione Enterprise si concentra su controllo, governance e evoluzione ripetibile dell'architettura. Mockomat Enterprise è progettato per le organizzazioni che necessitano del massimo isolamento, di funzionalità di conformità e della capacità di scalare la modellazione del dominio su più team.

Priorità Enterprise

I team Enterprise operano sotto vincoli diversi rispetto agli sviluppatori individuali o ai team di piccole dimensioni. Le priorità principali sono:

• Isolamento e confini chiari — separazione rigorosa tra tenant, progetti e dati.
• Esposizione controllata delle API — endpoint privati con accesso autenticato per ogni consumer.
• Stati architetturali riproducibili — la possibilità di ricreare o verificare qualsiasi stato del modello in qualsiasi momento.
• Flusso di modifiche verificabile — visibilità su chi ha modificato cosa, quando e perché.
• Prontezza alla conformità — pratiche di gestione dei dati che soddisfano i requisiti normativi.

ent-01-tenant-isolationMissing

Panoramica del modello di isolamento dei tenant e del runtime.

Isolamento dei tenant

Ogni cliente Enterprise opera all'interno di un tenant dedicato che fornisce confini rigorosi a ogni livello del sistema.

Isolamento dei dati

• Collezioni MongoDB separate — i dati mock di ogni tenant sono archiviati in collezioni isolate, mai mescolati con quelli di altri tenant.
• Query con ambito tenant — ogni query al database viene automaticamente filtrata per tenant ID, prevenendo la fuga di dati tra tenant.
• Spazi progetto indipendenti — i progetti all'interno di un tenant non condividono dati o configurazioni con progetti di altri tenant.

Isolamento del runtime

• Generazione di schema per tenant — gli schema GraphQL sono generati in modo indipendente per ogni progetto all'interno del tenant.
• Endpoint API isolati — ogni progetto riceve il proprio percorso endpoint, limitato ai controlli di accesso del tenant.
• Rate limiting indipendente — i limiti di richieste e il throttling sono configurati per tenant, non condivisi globalmente.

Isolamento della configurazione

• Limiti di sessione personalizzati — i tenant Enterprise possono impostare i propri limiti di sessioni simultanee e di API actor.
• Timeout di inattività personalizzati — i valori di timeout di inattività per sessioni e actor sono configurabili per tenant.
• Rate limiting personalizzato — i limiti di frequenza delle richieste possono essere adattati ai pattern di utilizzo dell'organizzazione.

ent-01b-isolation-architectureMissing

Livelli di isolamento di dati, runtime e configurazione.

Modello di governance

Un approccio pratico alla governance assicura che la modellazione del dominio rimanga coerente e di alta qualità man mano che l'organizzazione scala.

Ownership del dominio

Assegnare una ownership chiara per ogni area di dominio aziendale:

• Domain owner — responsabile della denominazione delle entità, della definizione degli attributi e della strategia delle relazioni all'interno del proprio dominio.
• Reviewer — membri del team che validano le modifiche prima che vengano promosse all'uso in produzione.
• Consumer — sviluppatori frontend e integratori che interrogano la mock API senza modificare il modello.

Convenzioni di denominazione condivise

Definire standard a livello organizzativo per:

• Denominazione delle entità — PascalCase, nomi singolari, linguaggio di business (es. Customer e non customers_tbl)
• Denominazione degli attributi — camelCase, descrittivi, senza abbreviazioni (es. totalAmount e non tot_amt)
• Denominazione delle relazioni — indicatori chiari di direzione e cardinalità
• Denominazione delle query — pluralizzazione coerente per le query di elenco, singolare per le query di dettaglio

Documentare queste convenzioni e distribuirle tramite blueprint interni in modo che ogni team parta con gli stessi standard.

Gate di revisione

Stabilire checkpoint di revisione nelle fasi chiave:

Fase	Focus della revisione	Chi revisiona
Modifica del modello	Coerenza della denominazione, completezza degli attributi, correttezza delle relazioni	Domain owner
Modifica dell'esposizione API	Superficie delle operazioni, denominazione delle query, impostazioni predefinite di paginazione	Domain owner + integratore
Validazione pre-esportazione	Comportamento runtime, correttezza di filtri/ordinamenti, attraversamento delle relazioni	Domain owner + QA
Revisione post-esportazione	Qualità del codice generato, confini dei moduli, copertura dei DTO	Responsabile del team di sviluppo

Criteri di validazione del runtime

Definire cosa significa "pronto" per ogni entità prima che possa essere promossa:

• Tutti gli attributi obbligatori hanno valori stabili e non nulli
• Tutte le relazioni si risolvono correttamente nell'anteprima
• Le operazioni di filtro e ordinamento funzionano su tutti i campi configurati
• La paginazione produce separazioni di pagina pulite
• Non rimangono hint o avvertimenti irrisolti

ent-02-governance-controlsMissing

Controlli di governance nelle fasi di modellazione e runtime.

Collaborazione di team

I piani Enterprise supportano team multi-utente con controllo degli accessi basato su ruoli.

Ruoli utente

Ruolo	Capacità
Admin	Accesso completo: creare/eliminare progetti, gestire i membri del team, configurare le impostazioni del tenant
User Admin	Gestire i membri del team, assegnare ruoli, visualizzare i log di audit
User	Creare e modificare progetti, eseguire l'anteprima, esportare backend
Guest	Accesso in sola lettura ai progetti condivisi e all'anteprima

Gestione delle sessioni simultanee

I tenant Enterprise supportano fino a 50+ sessioni simultanee (configurabile). Ogni sessione del browser autenticata viene conteggiata nel limite.

Comportamento delle sessioni:

• Le sessioni vengono tracciate in Redis con timeout di inattività configurabili.
• Quando una sessione è inattiva oltre il periodo di timeout, viene automaticamente rilasciata.
• Quando il limite di sessioni viene raggiunto, i nuovi tentativi di login vengono bloccati fino a quando una sessione non diventa disponibile.
• Gli amministratori possono visualizzare e gestire le sessioni attive.

Limiti degli API actor

Per il consumo esterno delle API, i tenant Enterprise possono configurare limiti di actor simultanei per API key:

• Predefinito: 20 actor simultanei per tenant
• Per API key: limiti configurabili per chiave per diversi consumer o ambienti
• Actor token: ogni consumer esterno riceve un actor token a tempo limitato che viene conteggiato nel limite di concorrenza
• Pulizia automatica: gli actor token scaduti vengono rilasciati automaticamente

ent-02b-team-collaborationMissing

Gestione dei membri del team e assegnazione dei ruoli.

Dataset personalizzati

I clienti Enterprise possono caricare e utilizzare dataset proprietari insieme alle fonti dati integrate di Mockomat.

Caricamento e mappatura

1. Caricare i dati — fornire il dataset in un formato supportato (CSV, JSON).
2. Estrazione dei metadati — Mockomat analizza il dataset e genera i metadati (nomi dei campi, tipi, valori di esempio).
3. Mappare sugli attributi — utilizzare i dati caricati come fonte di mappatura (esattamente come OFF_FIELD) per qualsiasi attributo nel modello.
4. Archiviazione isolata — i dataset personalizzati sono archiviati in collezioni isolate per tenant, mai condivisi con altri tenant.

Casi d'uso

• Dati specifici del settore — utilizzare cataloghi prodotti reali, directory dei dipendenti o dati di inventario per mock API più realistiche.
• Test di conformità — testare con dati che corrispondono alla forma dello schema di produzione senza utilizzare dati di produzione reali.
• Preparazione demo — creare mock API con dati realistici e personalizzati per le presentazioni ai clienti.

ent-03b-custom-datasetsMissing

Flusso di caricamento e mappatura dei dataset personalizzati.

Sicurezza e conformità

I piani Enterprise includono funzionalità di sicurezza avanzate per le organizzazioni con requisiti di conformità rigorosi.

Autenticazione

• Autenticazione JWT — ogni accesso alla management API richiede token JWT validi.
• Autenticazione tramite API key — i consumer esterni si autenticano con API key con ambito progetto.
• Actor token — token a tempo limitato per la gestione della concorrenza dei consumer API.
• Integrazione SSO/SAML — pianificata per le organizzazioni che richiedono una gestione centralizzata dell'identità.

Controllo degli accessi

• Accesso basato su ruoli — permessi granulari basati sul ruolo dell'utente (admin, user admin, user, guest).
• Permessi a livello di progetto — controllo su chi può accedere, modificare o esportare specifici progetti.
• Isolamento a livello di tenant — ogni accesso è automaticamente limitato al confine del tenant.

Protezione dei dati

• Nessun dato di produzione richiesto — le mock API utilizzano dati sintetici o supportati da dataset, mai informazioni reali dei clienti.
• Archiviazione isolata per tenant — i dati di ogni tenant sono archiviati separatamente e inaccessibili agli altri tenant.
• Comunicazione crittografata — tutto il traffico API utilizza HTTPS.
• Log di audit — tracciamento dei pattern di accesso, delle modifiche ai modelli e degli eventi di esportazione (pianificato).

Considerazioni sulla conformità

• Prontezza GDPR — i dati sintetici eliminano le preoccupazioni relative ai dati personali negli ambienti di sviluppo.
• Residenza dei dati — opzione di deployment on-premise per le organizzazioni con requisiti di sovranità dei dati.
• Politiche di conservazione — conservazione dei dati configurabile per sessioni e dati di utilizzo.

ent-03c-security-overviewMissing

Panoramica delle funzionalità di sicurezza e conformità Enterprise.

Deployment on-premise

Per le organizzazioni che necessitano del controllo completo sui propri dati e sulla propria infrastruttura, Mockomat offre un'opzione di deployment on-premise.

Cosa include:

• Un'istanza Mockomat self-hosted in esecuzione sulla propria infrastruttura
• Sovranità completa dei dati — tutti i dati rimangono all'interno della propria rete
• Configurazione personalizzata di dominio e SSL
• Integrazione con i sistemi di autenticazione esistenti
• Accesso diretto al database per casi d'uso avanzati

Requisiti:

• Ambiente di hosting compatibile con Docker
• Istanze MongoDB, MariaDB e Redis (servizi gestiti o self-hosted)
• Runtime Node.js (v20+)

Prezzo: $1,000 di setup + $199/mese di manutenzione (include aggiornamenti e supporto).

Runtime e aspettative operative

I team Enterprise dovrebbero trattare il comportamento del runtime come una superficie di qualità esplicita con standard misurabili.

Cosa aspettarsi

• Sufficientemente deterministico per la collaborazione — la stessa query produce la stessa forma strutturale ogni volta, consentendo ai membri del team di fare affidamento su un comportamento coerente.
• Sufficientemente trasparente per la revisione — ogni decisione del runtime (risoluzione dei filtri, lookup delle relazioni, ordine di ordinamento) è riconducibile alla configurazione del modello.
• Sufficientemente flessibile per l'iterazione controllata — i modelli possono evolvere senza interrompere i consumer esistenti, purché le modifiche vengano validate prima tramite l'anteprima.

Best practice operative

1. Definire i criteri di validazione per entità prima di assegnarla a un team.
2. Includere le verifiche runtime nei processi di revisione — trattare la validazione tramite anteprima come un passaggio obbligatorio.
3. Versionare le esportazioni del modello — mantenere uno storico dei backend generati associati agli snapshot del modello.
4. Monitorare l'utilizzo delle API — tracciare i pattern di richieste, i tassi di errore e i tempi di risposta su tutti gli endpoint.
5. Stabilire una cadenza di aggiornamento — programmare revisioni regolari del modello per mantenere le definizioni di dominio allineate con i requisiti di business in evoluzione.

ent-03-enterprise-runtimeMissing

Validazione del runtime Enterprise e checkpoint operativi.

Nota per l'implementazione Enterprise

Enterprise User

Si adotti un catalogo di dominio con ownership esplicita e una cadenza di revisione delle modifiche. Questa è la base per scalare l'architettura senza perdere chiarezza. Si inizi con un progetto pilota ridotto (un dominio, un team) e si espandano le pratiche di governance man mano che si integrano team aggiuntivi.

Nota per gli integratori in contesti Enterprise

Developer / Integrator

Si costruiscano pipeline di integrazione basate su snapshot stabili del modello e verifiche runtime documentate per ridurre le sorprese in fase di deployment. Si utilizzino API key versionate per ambiente (sviluppo, staging, produzione) e si validi il comportamento del runtime nella CI prima di promuovere le modifiche.