Come utilizzare gli attori per l'accesso al database e DDD?

Question

Non sono abbastanza sicuro di come gli attori possano essere utilizzati per accedere al database. Nella documentazione e nei libri per Akka questo argomento sembra essere omesso.

Una soluzione può essere un DAO avvolto in un attore senza stato. Ad esempio, per ogni tabella (o tipo di oggetto di dominio o tipo di aggregazione) nel database è possibile creare un attore responsabile di tutte le operazioni CRUD. Una variazione di questo può essere una separazione di comandi e query. Ad esempio per ciascun tipo di dati 1 comando attore (per concorrenza) e 10 query attori (per parallelismo).

Un altro approccio potrebbe essere quello di creare attori stateful che rappresentino esattamente una riga (o un'istanza dell'oggetto dominio o un'istanza aggregata) nel database. Naturalmente il database può essere in questo caso anche un archivio di eventi (come il modulo di persistenza akka) con una proiezione alla fine coerente a un database, un archivio di documenti o una cache. Questo non è rilevante qui. Questo approccio è in realtà un'implementazione di una cache in memoria con tutti i vantaggi e i problemi. Ci deve essere una strategia per distruggere gli attori per non rimanere a corto di memoria dopo un po '.

---

io dirigerò la mia domanda per DDD:

Diciamo, voglio sviluppare un'applicazione DDD con attori Akka. Concentriamoci qui sulla parte di comando. A mio avviso, questo dovrebbe essere implementato in questo modo: per ogni contesto limitato ci sarà un attore portuale, ad es. Spray REST API, che indirizza i messaggi all'appropriato attore del servizio di dominio. Questo attore del servizio coordina un'attività commerciale a uno o più aggregati di modelli di dominio. Ogni singolo aggregato è un attore di stato che viene ripristinato (o creato su nuovi dati) dall'attore del servizio dal database. L'attore del servizio invia/indirizza i messaggi a tutti gli attori aggregati coinvolti. Gli attori del modello di dominio ricevente eseguiranno la convalida aziendale sul loro stato + messaggio e quindi scriveranno le loro modifiche al database, ad es. DAO chiari. Dopo aver inviato un nuovo done all'attore del servizio, vengono arrestati. Al termine di tutti gli attori aggregati, un messaggio done viene rinviato al mittente del messaggio. Una variazione potrebbe essere quella di non fermare immediatamente gli attori del modello a dominio statistico, ma dopo un periodo di tempo, diciamo 3 minuti.

È un modello di utilizzo valido per DDD con Akka?

Answer 1

In genere le operazioni di lettura DB (cRud) possono essere eseguite direttamente da qualsiasi attore. Non è necessario effettuare alcuna manipolazione speciale nella maggior parte dei casi. Solo un semplice round robin per bilanciare il carico.

Come per le operazioni di aggiornamento (CrUD), possono essere suddivisi in domini/frammenti non intersecanti. Ad esempio, tutte le operazioni con un singolo account dovrebbero essere preferibilmente elaborate da un singolo attore. Uno può avere N attori di elaborazione quasi indipendenti e un router che indirizza i comandi a uno di essi sulla base dell'account.hashCode% N, ad esempio. Pertanto le operazioni verranno distribuite tra gli attori più o meno uniformemente e ogni account verrà elaborato in sequenza.

P.S. Slick sembra essere una libreria di db di discesa per le applicazioni Akka.