Implementazione di un modello aziendale pay-per-user

2

Introduzione

Sto lavorando a un'applicazione in cui le organizzazioni pagano per ogni utente che aggiungono al loro "ambiente". Le organizzazioni hanno un credito / equilibrio, e fintanto che l'utente non viene rimosso, l'organizzazione paga una piccola tariffa oraria per utente. Le organizzazioni possono scegliere tra pagamenti ricorrenti e una tantum. Una fattura verrà effettuata per ogni pagamento.

Sto cercando di trovare il modo migliore per implementarlo. Finora, ho trovato due soluzioni possibili:

Opzione A

La prima soluzione possibile è quella di "registrare" ogni cambiamento di stato nel sistema riguardante utenti, pagamenti e prezzi.

Quando un'organizzazione aggiunge o rimuove un utente, verrà scritta una voce di registro. Quando viene effettuato un pagamento, verrà scritta una voce di registro. Quando il prezzo cambia, verrà scritta una voce di log. Ogni stato rilevante verrà registrato.

Utilizzando questi registri, l'applicazione può calcolare il credito / saldo.

Opzione B

La seconda soluzione possibile è implementare un credito / equilibrio fisico. Invece di registrare tutto, verrà eseguito un cron job orario che sottrae la commissione per utente dal credito / saldo dell'organizzazione.

Questa seconda opzione mi sembra molto più semplice. Evita di fare tutti i tipi di calcoli complessi utilizzando più tabelle e record. Probabilmente avrò bisogno di registrare i pagamenti e roba lo stesso, ma non sto usando quei log per determinare il credito / il saldo.

Qualche idea? Qual è il modo migliore per implementare questo tipo di sistema?

Modifica

Dopo aver considerato la risposta di @ Ewan, credo che porti un buon punto. Ecco perché vado con l'opzione A, o qualcosa che assomiglia all'opzione A.

Ecco uno schema DB semplificato che ho creato:

Sembra che potrebbe funzionare?

    
posta Willem-Aart 15.11.2015 - 20:26
fonte

2 risposte

7

L'opzione A è di gran lunga superiore.

Immagina che il tuo lavoro cron si blocchi e non venga eseguito per un fine settimana. O trovi un bug e sta calcolando il prezzo leggermente sbagliato per età. Non avresti modo di capire le fatture corrette.

In qualsiasi sistema come questo devi considerare come verificherai i risultati. quindi devi essere in grado non solo di fatturare correttamente, ma tornare indietro e spiegare il calcolo del conto e dimostrare che è corretto.

    
risposta data 15.11.2015 - 23:14
fonte
1

Hai considerato qualcosa come una combinazione dei due?

Una volta all'ora, calcola l'addebito e registra tutto ciò che comprende quella carica in una tabella di sola scrittura. Quindi una volta / mese (o comunque lungo) una fattura può essere generata da tali dati. Se ci sono dispute o discrepanze, dovrebbe essere relativamente facile da rintracciare.

Questo non prende il posto di avere buoni registri, che è ciò che otterresti nell'opzione A.

    
risposta data 15.11.2015 - 20:37
fonte

Leggi altre domande sui tag