Utilizzo di root aggregati basati su eventi con il modello di specifica

Question

Utilizzo di root aggregati basati su eventi con il modello di specifica

#1 da (3 voti)

4

Ho una radice aggregata che usa la tecnica di sourcing degli eventi di essere costruita da una serie di eventi in un repository. Questo è tutto ottimo per quando ho solo bisogno di gestire il cambio di stato, ecc, ma quando arrivo a utilizzare il modello di specifica per applicare le regole di business specifiche dell'app, sto colpendo un muro su quali entità usare, come istanziarle ecc. Ecc. .

Vorrei eseguire metodi specifici sul mio repository, ad esempio getProductByProductCode in modo da poter controllare la mia corrente AR contro di essa per univocità (semplice esempio), ma non sono sicuro su come farlo, poiché il mio repository è impostato per ottenere le AR tramite il loro ID dall'archivio degli eventi.

Avevo un database che supportava i miei repository, ora ho solo un negozio di eventi perché non ho ancora modelli di lettura.

Qualcuno l'ha già fatto prima e come l'hai fatto?
Ho bisogno di un modello di lettura prima?
Devo interrogare il modello letto, quindi utilizzare un ID risultante per ottenere l'AR dall'archivio degli eventi?
Cosa succede se ho bisogno di più risultati AR da restituire?

Sono così confuso da pensare che stavo facendo tutto nel modo giusto ora che abbiamo bisogno di sourcing di eventi, ma non riesco a sposare il mio modo di pensare della vecchia scuola con il modo di farlo ora è l'evento originario :(

domain-driven-design aggregate cqrs event-sourcing

posta designermonkey 02.01.2018 - 15:52

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design aggregate cqrs event-sourcing

Quali sono le comuni / migliori pratiche per i framework che gestiscono eccezioni standard di terze parti? asp.net web api e architettura mvc per applicazioni web

score 3 · Accepted Answer

Repository is set up to get ARs by their ID from the event store.

Questo dovrebbe essere sufficiente. Se devi richiedere una raccolta di ARs dal repository, devi utilizzare un Read model appositamente progettato.

In altre parole, stai utilizzando CQRS. Ciò significa che non puoi eseguire una query su Aggregate per verificare che sia product code ed è naturale che tu non possa interrogare il repository, che fondamentalmente è una raccolta di Aggregati.

Has anyone done this before, and how did you do it?

Creo un modello di lettura veloce, leggero e appositamente progettato che risponde solo a questa domanda: bool isThereAlreadyAProductWithThisCode(string productCode) .

Do I need a read model first?

Sì. Vedi sopra.

Should I query the read model, then use a resulting ID to get the AR from the event store?

Solo se è necessario inviare comandi ad esso. Gli aggregati hanno solo metodi di comando (nessun metodo di query qualunque).

What if I need multiple AR results to be returned?

Quindi creane uno nuovo o modifica il modello Leggi sopra per rispondere a questa query.

I am so confused as I thought I was doing it all the right way now as we need event sourcing, but I can't seem to marry up my old-school thinking with how to do it now it's event sourced :(

È difficile perché ci sono due salti che devi compiere:

CQRS: esiste un modello di scrittura che riceve solo comandi (metodi che restituiscono void ). Non ha alcun metodo di query. In DDD, questo è Aggregate , con il suo punto di ingresso, Aggregate root . C'è anche uno o più modelli di lettura. Hanno metodi di interrogazione che rispondono a qualsiasi domanda degli altri livelli (ad esempio presentazione, applicazione, infrastruttura). Hanno anche metodi che aggiornano il loro stato persistente quando accadono eventi, ma questi metodi non devono essere usati dagli altri livelli. Dopo che gli eventi sono stati applicati a tutti i modelli di lettura, vengono scartati (non più utilizzati dal lato di scrittura). Quando arriva un comando, l'aggregato viene caricato da un repository in cui il suo stato semplice è stato mantenuto quando è stato gestito l'ultimo comando.
Sorgente di eventi: il modello di scrittura, in DDD Aggregato, non ha uno stato permanente normale. Ogni volta che arriva un comando, Aggregate viene reidratato dal negozio Eventi di new -ing una classe di Aggregate e quindi applica tutti i suoi eventi emmited precedenti (c'è un'ottimizzazione chiamata snapshoting ma agisce proprio come una cache e dovrebbe essere evitato se non proprio necessario). Non esiste un database che contenga lo stato Aggregates diverso da quello dell'evento.