Come gestisci l'estensibilità nei tuoi sistemi multi-tenant?

Ho affrontato un problema simile e ti dirò come sono andato a risolverlo.

1. In primo luogo, esiste una libreria o un motore "principale". Questo in pratica gestisce lo spettacolo, proprio come hai già capito. Gestisce le cose comuni a tutti i sistemi, dal rendering delle forme dinamiche, alla gestione degli account e degli utenti, ai ruoli, al nome, allo svolgimento.

2. Ogni parte del sistema è contenuta in un modulo. Un modulo ha dipendenze (altri moduli da cui dipende). Ad esempio, il sistema "core" ha Security (utenti, gruppi, ruoli, policy password), Locale, (traduzioni, paesi, culture), Repository file, Email, ecc. Ecc. Ogni modulo si definisce utilizzando un file xml. Il file xml fondamentalmente specifica gli schemi, le tabelle, le classi di calcolo, le definizioni delle schermate eccetera. Questi vengono letti quando l'applicazione inizia se la data del file è cambiata .

3. I moduli specifici del cliente hanno i propri file xml e la propria DLL. Tutto in più e funziona di conseguenza e in modo trasparente con il resto del sistema. Fino a sostituire le viste MVC esistenti con quelle personalizzate, con codice personalizzato e modelli di visualizzazione personalizzati.

4. Se un cliente desidera estendere le funzionalità esistenti, il xml / sistema fornisce un metodo in cui posso "derivare" un modulo da un altro. Il nuovo modulo ha tutte le funzionalità esistenti, ma con i requisiti specifici del cliente in una nuova DLL e con un file XML esteso in grado di apportare le modifiche. The Caveat è, non possono effettivamente rimuovere campi esistenti in questo sistema, ma possiamo estenderlo e fornire oggetti e funzionalità completamente nuovi.

Avere un sacco di logica di versioning e livelli di codice da gestire non aggiunge valore alla tua app / sito web. Richiede anche più potenza cerebrale per capire cosa sta succedendo e ti distrae dal nucleo di ciò che stai facendo.

Io consiglio diversamente. Ti consiglio di mantenere le cose semplici su complesse.

Mantenere una base di codice unica uguale per tutti. Ogni funzionalità che aggiungi è una funzionalità per tutti. Limita solo il numero di oggetti o di spazio di archiviazione o qualche cosa quantificabile, non le caratteristiche. Il motivo per cui sta quantificando cose come la memorizzazione, il numero di voci di dati, ecc è così semplice da programmare contro e può essere applicato a solo una piccola manciata di cose che limita davvero l'utente ad aggirare la tua app. Ha solo bisogno di essere programmato sull'aggiunta di elementi invece di fare qualche logica caratteristica. Cosa succede se le funzionalità sono legate ad altre funzionalità? Diventa molto complicato da codificare per questo.

Per qualificare la mia risposta, ho creato una struttura di e-commerce che ho per molti clienti e ho imparato a fondo nel tentativo di mantenere tutte le loro idiosincrasie. Ho finito per rompere la catena e creato un unico sito web di amministrazione che è multi-tennant per l'e-commerce. Poi ho dei siti Web che richiamano i dati dalle chiamate al servizio web. Ciò consente a diversi team in diverse tecnologie di implementare funzionalità specifiche per i siti di e-commerce mentre continuo a ricevere i pagamenti ogni mese sulla stessa infrastruttura e non mi interessa cosa stiano facendo. Limito solo l'utilizzo per numero, non per funzionalità. Il suo modo più facile. Il cliente è in grado di scegliere il proprio fornitore per costruire il proprio sito Web e io non sono più coinvolto in tali decisioni.

Ho anche un servizio in abbonamento per la gestione dei contenuti SAAS. Funziona anche con i livelli di utilizzo e i clienti possono aggiungere i propri plug-in se vogliono, mentre io ho il mio team per aggiungere più funzionalità per tutti.

Questa è solo la mia esperienza di sbattere la testa contro il muro dopo tanto tempo, poi inciampare su qualcosa di più semplice.

Se qualcosa è sempre specifico per ogni cliente, non creare un framework per questo. Scolparalo nelle sue parti più semplici in modo che la porzione di framework funzioni per tutti e quindi ritaglia il resto in modo da poterlo estendere per l'individuo.

Il prodotto software su cui lavoro ha campi aggiuntivi per l'estensibilità dell'utente. Ogni voce di dati per questi campi può essere associata a una riga esistente nelle tabelle principali dell'applicazione. Ad esempio se il tuo software contiene clienti e ciascun cliente un elenco di ordini, la tabella di dati personalizzabili avrà una colonna per le chiavi esterne per la tabella dei clienti e la tabella degli ordini, solo una delle quali sarà non nulla. O quello o un numero di tabelle ognuna con i campi personalizzati per una tabella.

Questo è un modo semplice e performante per memorizzare dati aggiuntivi per l'utente. Ulteriori informazioni dovrebbero essere archiviate sui nomi e i tipi di questi campi.

Questo copre i campi personalizzati per un cliente. Per comportamento personalizzato, un'API di servizi web consentirebbe l'estensione.

1) Eseguire il codice di qualcun altro sulle caselle che possiedi è un problema abbastanza difficile. O puoi fidarti di loro o puoi rinviare la responsabilità ragionevolmente, dovrai sandbox il loro codice molto pesantemente e avere una dedizione più alta della media. Poiché il tuo sistema di plugin consente più funzionalità, cresce la difficoltà di renderlo sicuro. Cose come la negazione del servizio (i plug-in consumano troppe risorse), la perdita di informazioni (i plug-in possono accedere ai dati degli altri inquilini), ecc. Possono essere molto reali e problematici, non prenderei parte a questo se non potessi far conoscere le persone questi problemi o persone molto capaci con un sacco di tempo per farlo bene.

2) Sì, la modularità e la personalizzazione sono difficili. Cose come il modello di strategia possono aiutare (un nome di fantasia per i puntatori di funzione, in Java è tipicamente implementato dichiarando un'interfaccia che gli utenti della classe possono implementare per personalizzare il comportamento del tuo codice), ma tu vuoi molto isolato e disaccoppiato codice per farlo funzionare.

3) Dal punto di vista dei dati, questo potrebbe essere uno degli esempi di archiviazione schemaless utile. Se si dispone di un modello di dati relazionali, è problematico disporre di tabelle con molte colonne per diversi clienti (sì, si finisce con un sacco di colonne nullable, che è non valido , una ragione è che è difficile o impossibile per impostare i vincoli corretti [vale a dire i vincoli che non consentono la visualizzazione di combinazioni di null non validi]). L'aggiunta di tabelle specifiche del cliente (vale a dire users e foo_users , con users che contiene i campi validi per tutti i clienti e foo_users con i campi specifici Foo) è migliore; puoi avere i vincoli corretti facilmente, ma il tuo RDBMS potrebbe non gestirlo con garbo (a causa dell'escursione dei join, dei limiti sul numero di tabelle, ecc.) e probabilmente avrà un aspetto brutto nel tuo codice.

Potresti finire per implementare un archivio di valori-chiave nel tuo RDBMS, il che rende il tuo modello di dati meno relazionale e causerà disagio (cioè i database relazionali funzionano meglio con i modelli relazionali-ish). Non sono sicuro che una soluzione NoSQL si adatti al problema in generale, ma la schematicità della maggior parte delle implementazioni potrebbe essere un vantaggio.