Raggruppamento / buffer di eventi di dominio

Question

Raggruppamento / buffer di eventi di dominio

#1 da (0 voti)

3

Supponiamo che abbia 3 eventi di dominio, Event1 Event2 e Event3. Quando il comando arriva al mio livello di servizio, posso aumentare 2 comandi contemporaneamente - ad es. Event1 ed Event2. Una classe ha un listener di eventi per entrambi gli eventi, ma in pratica dovrebbe attendere fino a quando non vengono ricevuti entrambi gli eventi per avviare l'elaborazione. Altrimenti ho bisogno di eseguire calcoli costosi 2 volte (1 ° quando viene ricevuto l'evento 1 e 2a volta quando viene ricevuto l'evento 2). C'è qualche schema di progettazione che può aiutarmi in questo?

L'unica cosa che mi viene in mente è che suppongo di poter avere un buffer e quindi attendere l'evento TRANSACTION_COMPLETE nel dominio per avviare l'elaborazione di tutti gli eventi ricevuti contemporaneamente.

domain-driven-design aggregate eventual-consistency event

posta Marko Kraljevic 23.08.2016 - 13:22

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design aggregate eventual-consistency event

Contatori in scadenza a Cassandra Java 8 time - LocalDateTime vs LocalDate e troncatoPer gestione delle limitazioni

score 0 · Answer 1

Suppose I have 3 domain events, Event1 Event2 and Event3. When command arrives at my Service Layer, I can rise 2 commands at the same time - e.g. Event1 and Event2. One Class has event listener for both events, but it should basically wait until both events are received to start processing it. Otherwise I need to execute expensive calculation 2 times (1st when event1 is received and 2nd time when event2 is received).

Is there some design pattern that can help me in this?

Potresti cercare un gestore dei processi . Un gestore di processi è essenzialmente una macchina a stati che passa da uno stato all'altro quando riceve un evento, in cui ogni stato descrive il lavoro in sospeso che stiamo aspettando.

Udi Dahan ha scritto una dimostrazione semplificata in Saga Persistence ed Event-Driven architetture . (Udi usa "saga" dove la maggior parte della comunità ora usa il gestore dei processi.)

A seconda delle strutture di dati che si stanno utilizzando per comunicare eventi ai gestori di eventi, si potrebbe fare bene a separare la lettura degli eventi dalle azioni intraprese. Ad esempio, la libreria Disruptor è progettata specificamente per l'idea di elaborare una serie di eventi in memoria e quindi agisci sulle modifiche quando raggiungi la fine del batch.

Nel tuo caso, ciò significherebbe che di solito elabori insieme Event1 ed Event2 (salvando il lavoro extra), ma in quei casi in cui Event2 è in ritardo, il gestore eventi può ancora fornire una risposta provvisoria all'interno del tuo SLA.