Che tipo di granularità è raccomandata nella programmazione reattiva quando si pubblicano eventi di cambiamento di stato?

Question

Che tipo di granularità è raccomandata nella programmazione reattiva quando si pubblicano eventi di cambiamento di stato?

#1 da (1 voti)

1

Attualmente sto sviluppando un'applicazione utilizzando la programmazione reattiva. Ogni creazione o modifica di entità nel sistema pubblica un evento e non è possibile creare / modificare due entità all'interno dello stesso caso d'uso.

In questa situazione, ci sono entità che devono essere create in base a stati specifici di altre entità. Ad esempio, esiste un'entità Slot che, una volta creata con uno stato IN_AUCTION, dovrebbe attivare la creazione di un'entità Asta. Questo è opzionale, poiché lo Slot può essere creato con uno stato DISPONIBILE, nel qual caso non è necessario creare un'Asta.

Dato questo caso, il mio dubbio riguarda il tipo di evento da pubblicare quando viene creato lo Slot. Queste sono le opzioni a cui ho pensato:

Pubblica un generico SlotCreatedEvent. In questo caso, il listener dovrebbe verificare lo stato dello Slot, aggiungendolo all'evento Slot o interrogandolo per verificarne lo stato.
Pubblica uno SlotInAuctionEvent o uno SlotAvailableEvent. In questo caso, ci sarebbe un listener specifico che creerebbe l'asta senza verificare lo stato dello slot ma se seguo questo approccio potrei avere un'esplosione di eventi.

Quindi, dato questo esempio, qual è la granularità attesa durante la pubblicazione degli eventi? Dovrebbe esserci un evento specifico per ogni modifica di stato / entità o solo uno generico con tutte le informazioni dell'entità modificate?

event-programming reactive event-handling

posta Kilian 08.02.2018 - 18:41

fonte

1 risposta

Leggi altre domande sui tag event-programming reactive event-handling

Solo una applicazione nel cluster esegue un lavoro Si sta confrontando "dollari-ore" per eseguire un pezzo di codice specifico come una stima delle prestazioni del sistema noleggiato?

score 1 · Accepted Answer

In linea di principio, penso che la cosa più comoda per i gestori di eventi dovrebbe essere una preoccupazione secondaria. Uno dei principali vantaggi degli eventi è che la fonte degli eventi non ha bisogno di sapere nulla dei consumatori - quindi non sai quali sono i loro bisogni.

La domanda si riduce a ciò che costituisce concettualmente un evento. Direi che la creazione di uno slot "in asta" e uno slot "non in asta" sono eventi separati non - altrimenti, si finisce con un evento separato per ogni combinazione di parametri.

Tuttavia, eviterete di inondare i vostri consumatori di informazioni non necessarie. Inoltre, penso che sia saggio evitare di inviare le stesse informazioni in diversi eventi, se possibile.

Nel tuo esempio, rischi di duplicare le informazioni sullo stato nell'evento SlotCreated e l'evento SlotStatusUpdated . Se dovessi reagire a uno slot "disponibile", dovresti iscriverti a due eventi.

Una possibile soluzione a questo problema potrebbe essere quella di pubblicare due eventi quando crei uno slot: l'evento SlotCreated non contiene informazioni sullo stato degli slot, ma otterrai anche immediatamente SlotStatusUpdated . Quindi AuctionCreator deve solo iscriversi a quest'ultimo. (Se SlotCreated non interessa a nessuno, puoi anche saltare questo evento).

Nota a margine: un modulo che deve solo reagire a nuovi slot con uno stato dato dovrà fare più lavoro in questo caso. Direi che questo è un riflesso naturale della condizione più complessa. (Se ci sono molti di questi abbonati, potresti avere un intermediario che combina entrambi gli eventi con un nuovo evento). In ogni caso, ci possono essere situazioni in cui questo approccio non è pratico, ma penso che di solito sarebbe una soluzione relativamente pulita.

Penso che possiamo riassumere le considerazioni precedenti nelle seguenti regole del pollice :

Se due eventi contengono le stesse informazioni, estraetele in un nuovo evento
Non creare un nuovo evento solo per soddisfare le esigenze di un abbonato

Purtroppo rimane aperta una domanda: abbiamo un evento StatusChanged o separato SlotOpenedForAuction , SlotReserved e SlotMadeAvailable eventi?

Potrebbe esserci un motivo tecnico per scegliere eventi separati: se hai un numero elevato di abbonati, ognuno dei quali deve gestire solo gli slot in uno stato particolare, gli eventi separati sono più efficienti. (Aumentare un evento è un'operazione O (n)). Altrimenti, dovresti utilizzare la terminologia del dominio come guida - ad esempio, gli utenti parlano dello "stato" di uno slot?