Devo usare cqrs + es per costruire un'app di slot machine?

0

per me l'app che sto costruendo, un'app per slot machine molto semplice in cui vi sono utenti che possono depositare denaro per acquistare crediti e utilizzare quei crediti per giocare alle slot machine e prelevare i loro guadagni. Questo è tutto.

Ho capito che l'individuazione di eventi ha senso in quanto abbiamo bisogno di una prova di tutte le transazioni e deve essere verificabile da un ente normativo.

L'immutabilità come un'unica fonte di verità sto pensando di usare Datomic. Tuttavia, non è chiaro per me dove CQRS / DDD sarebbe necessario se non del tutto. Ho difficoltà a giustificare l'aumento della complessità del progetto utilizzando DDD anziché una singola tabella utente con colonne di credito / denaro.

Sto diventando troppo avanti con me stesso applicando DDD usando il pattern CQRS? Non sono sicuro di quale sarebbe il vantaggio di separare i comandi dalla query per un gioco di slot machine molto semplice in cui apparentemente ha caratteristiche molto limitate (cambio di denaro per crediti, gioco, ritirare le vincite).

In definitiva, potrebbero esserci ulteriori vincoli aggiunti a seconda di dove viene distribuita l'app. Alcuni paesi potrebbero avere ulteriori processi normativi che devono essere aggiunti ...

Perché non posso semplicemente creare un'app CRUD e registrare un registro di tutto ciò che sta accadendo? Perché devo usare ES / CQRS / DDD? Ho addirittura bisogno di Datomic?

Ho solo bisogno di qualche secondo parere qui.

    
posta user299709 26.04.2016 - 03:07
fonte

1 risposta

1

a very simple

Questo probabilmente toglierebbe DDD dal tavolo. Se non stai anticipando un modello di dominio ricco e sottile, probabilmente supererai il punto di rendimenti decrescenti.

Why can't I just build a CRUD app

Se stai facendo questa domanda, è un altro suggerimento che DDD potrebbe non essere il cavallo giusto.

Ma andando dritti - il problema con un'app CRUD è una domanda: dove vive la business intelligence? Chi può decidere quali eventi sono legali?

Ad esempio: hai menzionato utenti che ritirano guadagni. Presumibilmente, non si vuole consentire all'utente di prelevare più di quello che ha guadagnato (l'alternativa suona come un pessimo modello di business, ma forse è possibile recuperarlo in volume). Allora, chi decide?

Se si dispone di un modello di dominio per il processo di ritiro delle entrate, è semplice: basta inviare un comando a un'entità che mantiene l'integrità dell'account e tale entità rifiuta i comandi che infrangono le regole. In un'implementazione CRUD ... dove vive questa logica?

Un altro modo di formulare questo è - dov'è il libro dei record? La tua app produce gli eventi o li consuma semplicemente?

(I consumatori puri sono in realtà un caso abbastanza comune. I sistemi di inventario del magazzino sono l'esempio canonico.)

Se la tua app per le slot machine è il libro dei record, probabilmente dovresti avere un modello di dominio per proteggere la tua attività. L'utilizzo di una cronologia di eventi per reidratare lo stato del modello ha alcuni vantaggi interessanti, quindi questa è una buona opzione.

Se stai usando il sourcing di eventi, allora stai pagando una piccola penalità sulle tue letture (gli storici degli eventi non sono ottimizzati per la lettura dello stato corrente, dopotutto), ma una interfaccia è più semplice di due, quindi l'adozione di quel modello è facoltativa.

Se stai anticipando un sacco di contesa, quindi essere in grado di rompere il tuo modello di dominio in parti isolate potrebbe aiutare il tuo ridimensionamento un po '. D'altra parte, se ogni app di slot machine è dedicata a un singolo account, sarà più semplice trattare l'intero dominio come una singola entità ai fini delle scritture.

Cavalli per i corsi.

    
risposta data 26.04.2016 - 06:18
fonte

Leggi altre domande sui tag