Un modello di dati di abbonamento SaaS

SaaS (Software as a Service) è uno dei tre componenti principali del Cloud computing. Di solito, le applicazioni SaaS sono basate sul Web e possono gestire molti utenti diversi contemporaneamente. Le soluzioni basate su abbonamento sono offerte SaaS molto popolari. Alcuni noti prodotti SaaS includono Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe e (ovviamente) Vertabelo! Oggi daremo un'occhiata a un modello di dati che ci permetterebbe di gestire gli abbonamenti SaaS.

L'idea

I prodotti SaaS possono essere molto diversi. Alcuni addebitano regolarmente i loro servizi, ad es. mensile o annuale; altri addebitano solo la quantità di tempo o risorse utilizzate (o una combinazione di queste due). Per semplificare le cose in questo articolo, mi concentrerò solo sugli abbonamenti a pagamento mensili.

Supponiamo di avere alcune soluzioni SaaS diverse e di dover tenere traccia di tutti i nostri abbonati in un unico database. Questo potrebbe essere il caso quando forniamo soluzioni di database (ad es. Amazon DynamoDB), strumenti di analisi (ad es. Amazon Athena) o applicazioni di robotica (ad es. AWS RoboMaker). Infatti, se guardiamo ad Amazon, possiamo vedere che ci sono molte diverse applicazioni disponibili. Sceglieremo solo quelli di cui abbiamo veramente bisogno.

Modello di dati

Il modello si compone di tre aree tematiche:

Users & groups
Software & plans
Subscriptions, plans & payments.

Descriveremo ciascuna di queste aree tematiche nell'ordine in cui sono elencate.

Sezione 1:Utenti e gruppi

Il Users & groups l'area tematica memorizza le informazioni su tutti gli utenti della nostra applicazione. Assumiamo che gli utenti possano essere raggruppati, ad es. quando un'azienda vuole acquistare licenze per più dipendenti. Creeremo un gruppo anche quando un solo utente appartiene ad esso. Questo ci darà la flessibilità di aggiungere in seguito nuovi membri a quel gruppo.

La tabella più importante qui è user_account tavolo. Lo useremo per memorizzare tutti i dettagli relativi agli account utente. Questi sono:

first_name & last_name – Il nome e il cognome dell'utente. Tieni presente che ogni utente memorizzato qui è un privato.
user_name – Un nome utente (scelto dall'utente).
password – Un valore hash della password dell'utente. (Gli utenti impostano le proprie password.)
email – L'indirizzo email dell'utente, impostato durante il processo di registrazione.
confirmation_code – Il codice utilizzato durante il processo di conferma via e-mail.
confirmation_time – Quando la registrazione/conferma è stata completata.
insert_ts – Il timestamp in cui questo record è stato inizialmente inserito.

Gli utenti possono creare gruppi; i gruppi hanno tipi predefiniti. Un elenco di tutti i possibili tipi di gruppo è memorizzato in user_group_type tavolo. Ogni tipo è UNICAMENTE definito dal suo type_name . Definiremo anche il numero minimo e massimo di membri del gruppo consentiti per ogni tipo di gruppo. Tale intervallo è definito con due valori:members_min (il limite inferiore) e members_max (il limite superiore).

Durante la creazione di un nuovo account, gli utenti selezioneranno anche il proprio gruppo di utenti. Questo creerà un nuovo record nel user_group tabella che fa riferimento al tipo di gruppo selezionato e che memorizza il timestamp (insert_ts ) quando questo record è stato inserito. I customer_invoice_data è una descrizione testuale di ciò che stamperemo sulla fattura per quel gruppo di utenti.

L'ultima tabella in questa area tematica è in_group tavolo. Per ogni gruppo, memorizzeremo un elenco di tutti i suoi membri. Oltre ai riferimenti al gruppo utenti (user_group_id ) e account utente (user_account_id ), memorizzeremo anche il timestamp quando un utente è stato aggiunto al gruppo (time_added ) o rimosso dal gruppo (time_removed , che conterrà un valore solo se l'utente è stato rimosso). Avremo anche un flag per indicare se l'utente è il group_admin o no. Gli amministratori del gruppo possono aggiornare i membri del gruppo e aggiungere nuovi membri.

Sezione 2:Software e piani

Successivamente, dobbiamo definire tutto ciò che offriremo ai nostri (potenziali) clienti. Potremmo offrire un solo tipo di software, ma c'è una grande possibilità che avremo diverse offerte diverse. Un esempio comune di questo caso è avere uno strumento SaaS separato dalla sua applicazione di analisi, ad es. Riga e Riga Sigma. Tratteremo questi casi nel nostro modello di dati.

Inizieremo con il software tavolo. In questo dizionario memorizzeremo un elenco di tutte le nostre offerte SaaS. Per ognuno memorizzeremo:

software_name – Un nome software UNICO.
details – Tutti i dettagli che descrivono quel software.
access_link – Una posizione o un collegamento in cui possiamo accedere a quel software.

Dovremmo essere in grado di offrire le nostre soluzioni SaaS in uno o più piani diversi. Ogni piano contiene varie opzioni. Ad esempio, potremmo avere un piano premium che includa tutte le opzioni che offriamo e un piano base che includa solo l'essenziale. Conserveremo tutti i piani distinti nel plan tavolo. Per ogni piano definiremo:

plan_name – Il nome che abbiamo selezionato per questo piano. Insieme al riferimento al software (software_id ), costituisce la chiave alternativa/UNICA di questa tabella.
user_group_type_id – Un riferimento che denota il tipo di gruppo che può utilizzare questo piano. Potrebbe trattarsi di un gruppo di utenti singoli o di un gruppo standard. Questo riferimento definisce anche il numero massimo di membri del gruppo per quel piano, ad es. se il nostro piano consente cinque account diversi su un abbonamento, dovremmo fare riferimento al user_group_type appropriato .
current_price – Il prezzo corrente per questo piano.
insert_ts – Il timestamp in cui è stato inserito questo record.
active – Un flag che indica se questo piano è attivo o meno.

Abbiamo già detto che i piani per lo stesso software avranno opzioni diverse. Un elenco di tutte le opzioni distinte è memorizzato nell'option dizionario. Ogni opzione è UNICAMENTE definita dal suo option_name .

Per assegnare opzioni a piani diversi, utilizzeremo option_included tavolo. Memorizza i riferimenti al relativo piano (plan_id ) e opzione (option_id ). Questa coppia, insieme a date_added attributo, costituisce la chiave UNICA di questa tabella. Il date_removed l'attributo conterrà un valore solo se abbiamo deciso di rimuovere una determinata opzione da un piano. Questo potrebbe accadere quando costruiamo una nuova opzione per sostituire quella precedente o decidiamo di non avere più una determinata opzione perché poche persone la usano.

L'ultima parte di questa area tematica è relativa a offerte speciali o promozionali. In generale, tali offerte offrono ai clienti più servizi per meno soldi e durano per un certo periodo di tempo. Potrebbero essere mirati all'acquisizione di nuovi clienti o alla vendita di aggiornamenti del piano (o una gamma più ampia di servizi) a clienti esistenti.

Tutte le nostre offerte promozionali sono memorizzate nell'offer tavolo. Per ogni offerta, dovremo definire:

offer_name – Un nome UNICO che abbiamo selezionato per questa offerta.
offer_start_date e offer_end_date – Il periodo di tempo durante il quale questa offerta è disponibile.
description – Una descrizione testuale dettagliata dell'offerta.
Sconti:abbiamo bisogno della flessibilità per avere due tipi di sconti:uno sconto basato su un importo fisso (ad esempio ricevi $ 50 di sconto) e uno sconto percentuale (ad esempio risparmia il 25%). Se offriamo uno sconto fisso, inseriamo quel valore nel discount_amount attributo; se offriamo una percentuale di sconto, la inseriamo nel discount_percentage attributo.
Durata:qui utilizzeremo la stessa logica utilizzata per gli sconti. In alcuni casi, le offerte dureranno per un numero definito di mesi (ad es. per 24 mesi dopo la registrazione dei clienti); in questi casi, definiremo la duration_months valore. Altre offerte saranno valide fino ad una certa data fissata (es. fino al 31 dicembre 2019); per questi, definiremo la data e la memorizzeremo nel duration_end_date attributo.

Utilizzeremo le restanti due tabelle in questa area tematica per definire cosa contiene ogni offerta e quali prerequisiti ha. A tale scopo, utilizzeremo due tabelle:include e prerequisite . Condividono la stessa struttura e contengono la stessa coppia UNICA di offer_id – plan_id . Alcune offerte potrebbero non avere alcun prerequisito, mentre altre potrebbero, ad es. se offriamo uno sconto per l'aggiornamento a un piano con più utenti o un abbonamento software per gli utenti di qualche altro software.

Le offerte possono essere complesse, quindi fornirò alcuni esempi.

Se attualmente utilizziamo il piano A e abbiamo un'offerta per l'aggiornamento al piano B, questo è semplice.
Se abbiamo due offerte, "Piano A upgrade al Piano B" e "Piano B upgrade al Piano C", dovremmo creare un'altra offerta:"Piano A upgrade direttamente al Piano C". Ciò consente agli utenti di aggiornare i propri piani in un passaggio anziché in due. Un esempio di tale aggiornamento è la modifica di un abbonamento che attualmente consente cinque utenti per gruppo a uno che consente 20 utenti per gruppo senza fermarsi a un piano intermedio, dieci utenti per gruppo lungo il percorso.
Se un gruppo utilizza il Prodotto A, potremmo avere un'offerta speciale per abbonarsi ai Prodotti B e C a un prezzo promozionale. Potremmo anche avere due offerte separate per abbonarsi solo al Prodotto B e solo al Prodotto C.

In generale, dovremmo avere un'offerta che cambierà il piano attuale nel piano desiderato senza passaggi intermedi e solo un'offerta per abbonarsi a uno o più nuovi prodotti.

Sezione 3:Abbonamenti, piani e pagamenti

L'ultima area tematica collega le due aree precedentemente citate ed è il vero cuore di questo modello.

Tutti gli abbonamenti sono memorizzati nel subscription tavolo. Tratteremo ogni piano diverso come un abbonamento separato, anche se questi abbonamenti/piani sono il risultato della stessa offerta. Il motivo è che saremo in grado di gestire gli abbonamenti separatamente, ad es. cancellali separatamente se volessimo. Dovremo definire una serie di dettagli qui:

user_group_id – L'ID del gruppo che sottoscrive questo piano. Questo è importante perché gli utenti non saranno iscritti individualmente; sono iscritti indirettamente, come parte del gruppo.
trial_period_start_date e trial_period_end_date – I limiti inferiore e superiore del periodo di prova (se presente) per questo abbonamento.
subscribe_after_trial – Un flag che indica se l'abbonamento verrà rinnovato automaticamente al termine del periodo di prova (se presente).
current_plan_id – Il piano corrente per quell'abbonamento. Se l'abbonamento non è più attivo, questo attributo conterrà il valore dell'ultimo piano attivo.
offer_id – Un riferimento all'offerta a cui è correlato questo abbonamento. Questo attributo conterrà un valore solo se questo abbonamento è stato il risultato di una determinata offerta.
offer_start_date e offer_end_date – Il limite inferiore e superiore del periodo durante il quale questa offerta è stata attiva. Questi attributi verranno definiti solo se questo abbonamento è il risultato di una determinata offerta.
date_subscribed – Quando questo gruppo si è iscritto a questo abbonamento.
valid_to – L'ultima data di validità dell'abbonamento. Nel caso di un abbonamento mensile, possiamo aspettarci che valid_to sarà impostato alla fine del mese corrente. Se un cliente annulla l'iscrizione in qualsiasi momento durante un mese, sarà comunque in grado di utilizzare il proprio software fino alla fine del mese.
date_unsubscribed – La data in cui il gruppo ha annullato l'iscrizione a questa sottoscrizione. Possiamo aspettarci che questa data venga impostata manualmente dall'amministratore del gruppo quando il gruppo decide di non utilizzare più il servizio. Tuttavia, potrebbe anche essere impostato automaticamente, secondo criteri predefiniti, ad es. annullare automaticamente l'iscrizione di un gruppo al suo servizio se sono presenti due o più fatture non pagate.
insert_ts – Il timestamp in cui è stato inserito questo record.

I piani di abbonamento cambiano spesso nel tempo. Per mantenere una cronologia completa di tutti i nostri piani, memorizzeremo tutte le modifiche al piano in plan_history tavolo. Per ogni record qui, avremo bisogno di:

subscription_id – L'ID del relativo abbonamento.
plan_id – L'ID del relativo piano.
date_start e date_end – Il periodo di tempo in cui questo piano era attivo.
insert_ts – Il timestamp in cui è stato inserito questo record.

L'ultima tabella nel nostro modello memorizzerà le nostre invoices . Per ogni fattura conserveremo i seguenti dettagli:

customer_invoice_data – Una descrizione del cliente fatturato per questa fattura. Questi saranno i dati di user_group.customer_invoice_data al momento della generazione della fattura.
subscription_id – L'ID del relativo abbonamento.
plan_history_id – L'ID del piano attivo durante questo periodo di fatturazione.
invoice_period_start_date e invoice_period_end_date – L'intervallo di tempo (ad es. dal 1 gennaio 2019 al 31 gennaio 2019) coperto da questa fattura.
invoice_description – Una breve descrizione testuale della fattura.
invoice_amount – L'importo del pagamento dovuto per questa fattura.
invoice_created_ts – Quando questa fattura è stata generata e inserita nella tabella.
invoice_due_ts – Quando questa fattura è scaduta.
invoice_paid_ts – Il timestamp in cui è stata pagata questa fattura.

Dicci cosa ne pensi del modello di dati SaaS

Immagino che la maggior parte di voi abbia incontrato SaaS, sia come sviluppatore che come utente. Non vedo l'ora della tua opinione su di esso e su questo modello di dati. Sentiti libero di condividere le tue esperienze e suggerimenti nei commenti qui sotto.