In un SaaS in cui una persona può lavorare in più organizzazioni o workspace, «chi ha creato questa risorsa?» non risponde necessariamente alla domanda «a chi appartiene?». La differenza influisce su chi può vederla, modificarla, trasferirla o conservarla quando qualcuno lascia un team. Risolvere la questione troppo tardi spesso lascia regole sparse tra query, controller e attività in background.
La proprietà delle risorse in un SaaS multiutente è una decisione di dominio: determina quale entità ha la relazione principale con una risorsa e quali conseguenze comporta tale relazione. Non è sinonimo di autenticazione, appartenenza o permessi. Modellarla in modo esplicito permette a prodotto, dati e codice di condividere una regola coerente.
Identità, appartenenza e proprietà sono relazioni distinte
Un utente rappresenta un’identità che può effettuare l’accesso. L’appartenenza indica che quell’identità partecipa a un’organizzazione o a un workspace, eventualmente con un ruolo o uno stato. La proprietà indica quale entità è responsabile di una risorsa secondo le regole del prodotto. Una persona può appartenere a più workspace e, allo stesso tempo, creare un documento che appartiene a uno di essi.
È opportuno distinguere anche l’autorialità, cioè chi ha creato la risorsa. Il campo created_by può conservare l’identità di chi ha eseguito l’azione iniziale, ma non dovrebbe determinare da solo la proprietà. Se chi ha creato il record lascia l’organizzazione, la risorsa può continuare ad appartenere a quest’ultima. Viceversa, una persona potrebbe acquisire una risorsa creata originariamente da un’altra.
È utile documentare le risposte a tre domande: chi è il proprietario, chi può operare sulla risorsa e chi ha eseguito ogni azione rilevante. Se lo stesso campo o la stessa relazione pretende di rispondere a tutte, probabilmente il modello sta mescolando concetti diversi.
Scegliere tra proprietà personale, organizzativa o condivisa
- Personale: la risorsa appartiene a un utente. Ha senso quando il suo ciclo di vita segue quello della persona e non di un team, come nel caso di una preferenza privata. Occorre decidere cosa succede se l’account viene disattivato o eliminato.
- Organizzativa: appartiene a un’organizzazione o a un workspace. È adatta quando la risorsa deve restare disponibile al team anche se cambiano i suoi membri. L’appartenenza dell’utente consente l’accesso, ma non lo rende proprietario individuale.
- Condivisa: più entità possono avere un rapporto di titolarità o responsabilità. Usala solo se il dominio richiede davvero la comproprietà. Se il requisito è consentire a più persone di consultare o modificare una risorsa, di norma si tratta di accesso tramite membership o permessi, non di più proprietari.
La decisione deve seguire il ciclo di vita della risorsa e le regole di business, non la preferenza per una tabella più semplice. Chiediti chi può conservarla, deciderne l’eliminazione e farsene carico quando il team cambia. Distingui anche «workspace» da «organizzazione»: se il primo è una vera suddivisione, con un proprio ciclo di vita e propri confini, può essere il proprietario appropriato; se è solo una vista o un contesto di navigazione, forse non lo è.
Rappresentare il dominio senza dedurre il proprietario
In un modello semplice, una tabella delle risorse può avere un proprietario esplicito, per esempio owner_type e owner_id, oppure riferimenti separati come user_id e organization_id. La prima opzione può facilitare la gestione di più tipi di proprietario, ma richiede di convalidare i riferimenti e di considerare i limiti di integrità referenziale delle relazioni polimorfiche. I riferimenti separati rendono i collegamenti più espliciti, ma richiedono di impedire combinazioni non valide.
Un’altra alternativa è un’entità comune, per esempio workspace, se il dominio rappresenta davvero sotto di essa sia gli account personali sia i team. Non introdurla solo per nascondere le differenze: deve avere un significato e regole stabili. In qualsiasi progettazione, definisci vincoli che impediscano a una risorsa di essere associata contemporaneamente a proprietari incompatibili o a nessun proprietario quando la proprietà è obbligatoria.
Modella separatamente le membership, per esempio con una relazione tra utente e organizzazione che includa stato e ruolo. Il contesto attivo dell’interfaccia può indicare dove sta lavorando la persona in quel momento, ma non è sufficiente come autorità: deve essere convalidato a ogni operazione. Allo stesso modo, il proprietario non deve essere calcolato come «chi ha creato la risorsa» né come «l’organizzazione attualmente selezionata».
Applicare la proprietà a letture, scritture e processi automatici
Le query devono includere l’ambito di proprietà e un controllo degli accessi appropriato. Non basta caricare la risorsa tramite identificatore e confidare che l’interfaccia nasconda quelle non pertinenti. In un’applicazione PHP, centralizza la risoluzione del contesto e le regole di autorizzazione in un livello riutilizzabile, ed evita di replicare condizioni incomplete in ogni controller.
In scrittura, convalida il proprietario consentito e l’appartenenza attuale dell’attore. Verifica anche che le risorse correlate — per esempio una cartella di destinazione — appartengano a un ambito compatibile; in caso contrario, un aggiornamento può creare associazioni incrociate. Per le operazioni amministrative, separa in modo esplicito le autorizzazioni eccezionali dalle regole ordinarie e registra chi le ha eseguite e perché.
Le code, i comandi pianificati, i webhook e le importazioni non hanno sempre un utente interattivo. Devono trasportare un identificatore del proprietario o un contesto convalidato, invece di dipendere da una sessione implicita. Il processo deve applicare le stesse regole di ambito dell’applicazione web. Se opera con privilegi più ampi, limita tali privilegi e sottoponili ad audit.
Gestire il trasferimento come un’operazione di dominio
La modifica del proprietario non dovrebbe essere una generica modifica di un campo. Definisci le precondizioni: chi può avviare il trasferimento, quale relazione deve avere il destinatario con il workspace e cosa fare in caso di invito in sospeso o account inattivo. Quando aggiorna più relazioni ed effetti associati, l’operazione dovrebbe essere atomica.
Stabilisci anche cosa succede alle dipendenze, come file, integrazioni, fatturazione o automazioni. Non dare per scontato che tutto debba essere trasferito insieme alla risorsa: la scelta dipende dal prodotto. Se non è possibile completare tutte le modifiche in un’unica transazione, progetta un processo recuperabile, con stati chiari e idempotenza per i nuovi tentativi.
Conserva un audit log con l’attore, il proprietario precedente, quello nuovo, il momento e il motivo, quando pertinente. In questo modo si distingue chi ha autorizzato la modifica da chi ha eseguito l’azione tecnica. L’autorialità originale può essere mantenuta invariata anche se cambia la titolarità.
Testare i confini che rivelano errori di modellazione
Automatizza test di servizio e di integrazione per verificare sia gli accessi consentiti sia quelli negati. Una matrice utile include una persona appartenente a due organizzazioni, risorse proprie e altrui in entrambe, membership sospese o revocate, trasferimenti verso una destinazione non idonea e accessi tramite identificatori noti. Verifica le risposte e gli effetti sui dati: nascondere un pulsante non costituisce un test di autorizzazione.
Testa anche le risorse prive di un proprietario valido, le relazioni duplicate e gli errori durante un trasferimento. Se lo schema richiede un proprietario, i vincoli del database devono supportare questa aspettativa e le migrazioni devono rilevare i record storici incoerenti prima di aggiungere i vincoli. Per le attività in background, verifica che il contesto venga mantenuto e che un nuovo tentativo non duplichi le modifiche.
Checklist prima di ampliare il SaaS
- È stato definito se ogni tipo di risorsa appartiene a una persona, a un’organizzazione o a un workspace?
- La proprietà è distinta dall’autorialità, dall’appartenenza, dal ruolo e dal contesto attivo?
- Le query di lettura e scrittura convalidano il proprietario e la membership attuale?
- Le attività automatiche ricevono un ambito esplicito e applicano controlli equivalenti?
- Il trasferimento ha precondizioni, effetti definiti, audit e una strategia di recupero?
- Esistono test per utenti con più workspace, disattivazioni o abbandoni, accessi incrociati e dati incoerenti?
Se una risposta dipende da convenzioni non documentate, è opportuno chiarirle prima di aggiungere altri tipi di risorse o flussi di collaborazione. Un modello esplicito non elimina tutti i casi complessi, ma rende visibili le decisioni e permette di verificarle nello schema, nelle query e nei test.
