Memorizzazione dei dati del conto bancario utilizzando Event Sourcing

Question

Memorizzazione dei dati del conto bancario utilizzando Event Sourcing

#1 da (1 voti)

0

Cercando di modificare le cose relative ai pagamenti nel progetto corrente, ma non si è ancora potuto decidere sull'architettura di piccole parti. Spero che tu possa condividere i tuoi feedback.

Flusso e stato: Abbiamo un conto di pagamento con il quale inviamo denaro (conti paypal, swift o iban), ogni volta che l'utente vuole (1) aggiungere / aggiornare il proprio account di pagamento, archiviamo i dati da aggiornare nel campo confirm_this_data_table.JSONB (come era in richiesta), quindi (2) inviamo un'email di conferma, dopo (3) confermando questi dati lo recuperiamo dall'archivio JSON e lo aggiungiamo alla tabella payment_accounts. L'utente potrebbe avere più payment_accounts.

Stato attuale e il suo problema Diciamo che abbiamo A, B e C payment_accounts. L'utente modifica l'account "A" e cambia il numero rapido. Nella nostra soluzione attuale questi dati saranno sostituiti con nuovi dati, il che significa che abbiamo perso i dati storici per la verifica , probabilmente inviamo il pagamento al vecchio account, ma non possiamo provarlo, perché stiamo facendo riferimento all'account che è stato modificato

Pensando a questo Table :

id (sequenza)
user_id
account (diciamo in jsonb, probabilmente non ha importanza in questo contesto)
confirmation_token (stringa casuale)
uuid (uuid4 per l'identificazione univoca di questo payment_account)
start_date
deleted_at

Portata:

l'utente aggiunge payment_account (nuova riga creata e reso token per conferma, diciamo uuid = abcd-efg)
conferma il token dell'utente (la data_iniziale verrà aggiornata con la data corrente, il che significa che l'account è ora attivo)
l'utente aggiorna questo pagamento (di nuovo una nuova riga creata, questa volta con vecchio uuid = abcd-efg, perché stiamo aggiornando, il token è ritornato)
l'utente conferma il token, ora start_date impostato su current_date
quando l'utente cancella questo account con uuid = abcd-efg, impostiamo deleted_at = current_date

Idealmente mi piacerebbe avere una soluzione con l'event sourcing (non voglio emettere una query UPDATE)

Vedi qualche problema con questa soluzione?

Puoi consigliare una soluzione che INSERISCE solo i dati, ma allo stesso tempo non richiede la riproduzione di tutti gli eventi o richiede query sofisticate per recuperare i dati?

architecture review event-sourcing

posta user1318496 26.06.2018 - 00:58

fonte

1 risposta

Leggi altre domande sui tag architecture review event-sourcing

for-loops vs x.Times (...) metodi di estensione Posso usare Dependency Injection per testare la mia classe quando è necessario un costruttore senza parametri?

score 1 · Accepted Answer

Can you recommend solution which only INSERTs data, but at the same time doesn't require re-playing all events or requires sophisticated queries to retrieve data?

Mi sembra che tu abbia l'idea giusta; ma per scriverlo: in molti domini, c'è un concetto di dominio per "data effettiva". Non una proprietà che è vera per sempre e sempre, ma piuttosto una che ha una durata limitata (anche se il punto finale potrebbe non essere ancora conosciuto).

Quindi rendi quest'idea esplicita nel tuo modello, che ora include solo una storia di append; quando apporti le modifiche al modello, non sono distruttive e puoi ripristinare la cronologia dell'account.

L'approccio non è esente da sfide: spesso accade che la maggior parte dei casi d'uso non abbia bisogno di tutti dei dati storici. Quindi c'è qualche tentazione di ottimizzare il carico dei dati dall'archivio di persistenza. Potrebbe essere difficile o facile, a seconda di quali altri vincoli sono coinvolti (ovvero "dipende").