Come modellare un evento complesso nel sourcing di eventi?

Question

Come modellare un evento complesso nel sourcing di eventi?

#1 da (1 voti)
#2 da (0 voti)

0

Diciamo che abbiamo un utente (come un supereroe) che vuole vedere tutte le guerre che sta accadendo in un mondo in modo che possa fermarle. Non può impedirli tutti, perché ha bisogno di dormire a volte e così via. Ma se una guerra è accaduta mentre dormiva, vuole saperlo (quindi può punire chi l'ha iniziato, per esempio).

Quindi, se la guerra è iniziata, vuole vedere dove è successo e quando. E anche tutti gli eventi su questa guerra, come alcune battaglie per esempio.

Quindi vuole un software in grado di presentargli queste informazioni in un "tavolo di guerra" dove può vedere tutte le guerre a cui non ha ancora reagito in alcun modo.

E questo è un software che ho bisogno di scrivere.

Quindi diciamo che ho un software che monitora alcuni stati e basato su eventi di livello inferiore genera eventi come "War started", "War ended", "Battle started", "Battle ended", "War changed location" ecc. .

Il problema che mi turba è che al tempo in cui la guerra era iniziata, la guerra è un processo, non un evento. Perché la guerra sta ancora accadendo. Ma dopo l'evento "War ended" possiamo dire che questo processo è terminato e ora è un evento.

Per essere più concreti. Diciamo che la sequenza di eventi è:

'War1 iniziata nella posizione x1' 'War2 ha iniziato nella posizione x2' "War1 ha cambiato posizione in x4" "War2 ha cambiato posizione in x5" 'War1 ha una nuova battaglia iniziata nella posizione x3' 'War1 ha una nuova battaglia finita nella posizione x3' 'War1 terminato'

Ma l'utente non vuole vederlo come una sequenza. Quello che vuole vedere è qualcosa di simile a questo

'War1 sta succedendo nella posizione x1' "War2 sta accadendo nella posizione x2"

Quindi vuole che la prima riga cambi in base al prossimo evento

'War1 sta accadendo nella posizione x4' "War2 sta accadendo nella posizione x2"

e così via

'War1 sta accadendo nella posizione x4' "War2 sta accadendo nella posizione x5"

e così via fino alla fine di queste guerre.

'War1 era in posizione' qualche posizione '' 'War2 era in posizione' qualche altra posizione ''

Come puoi vedere war1 e war2 sono eventi ora.

Dopo che la guerra è finita, il supereroe vuole ancora sapere tutte le informazioni a riguardo, se vuole, ma in questo tavolo di guerra vuole sostanzialmente vedere le informazioni attuali sul processo di guerra.

In questo momento la soluzione è pensare a questo processo di guerra come processo, che può ancora andare o essere già finito. Il problema è che in questo caso se vogliamo monitorare un evento diverso dalla guerra e più semplice (come un interruttore che può essere solo attivato o disattivato) avremmo un modello come un processo che ha un orario di inizio e tempo di stop. Che è ... strano, penso.

Ho pensato a una soluzione diversa. Invece di visualizzare i processi, visualizza gli eventi di livello inferiore raggruppati per argomento.

Come "War 1 have started" e "War 1 has ended" hanno lo stesso soggetto - processo "War 1".

Ma non tutti gli eventi nel nostro sistema avrebbero un processo come soggetto e ... Sono un pazzo di perso qui.

Forse qualcuno ha già fatto qualcosa del genere? Quale potrebbe essere l'approccio corretto a questo?

event-sourcing

posta user1685095 24.06.2015 - 22:28

fonte

2 risposte

Leggi altre domande sui tag event-sourcing

Perché la definizione 'class String' ha un modificatore 'finale'? [duplicare] problemi che compongono una funzione con un tratto Aggiungi in Rust [closed]

score 1 · Answer 1

Ho diverse idee sulla tua domanda.

Ciò di cui stai parlando è fatto in un contesto più ampio con pattern come CQRS (Command Query Responsibility Separation) e Event Sourcing, e "lambda architecture".

Questi schemi architetturali riguardano la scala, la tolleranza ai guasti / il recupero. Essenzialmente Event Sourcing acquisisce e persiste gli eventi nel sistema come una struttura di log di sola aggiunta, alcuni processi leggono i log e i feed in un database di qualche tipo che mantiene lo stato corrente traducendo ogni evento in un aggiornamento del database; la tolleranza agli errori e il ripristino dall'incidente del database vengono eseguiti rileggendo il registro eventi. Altre parti dell'architettura mantengono diverse rappresentazioni dello stato corrente, uno potrebbe essere ottimizzato per la scrittura (normalizzato) un altro ottimizzato per la lettura (denormalizzato secondo le query dell'applicazione).

Sebbene questi pattern siano probabilmente applicati su scala maggiore di quanto si stia tentando, l'idea alla base è simile - per tradurre tra diverse rappresentazioni, che iniziano con gli eventi e vanno verso lo stato corrente (in diverse rappresentazioni per scopi diversi). / p>

In un'altra nota, direi che un evento è associato a un orario (quando si è verificato l'evento) e un processo con un'ora di inizio e un'ora di fine. Alcuni processi sono in corso, ma tutto ciò significa che non conosciamo il loro tempo di fine (ancora). Solo perché un processo termina (cioè, apprendiamo la loro ora di fine) non lo converte in un evento, è pur sempre un processo.

Dovresti assolutamente provare ad avere un "oggetto" dei tuoi messaggi. Ciò aiuterà a tradurre gli eventi nello stato corrente. A mio parere, la modellazione delle informazioni dovrebbe tentare di catturare e rappresentare i fatti. I fatti possono essere rappresentati da frasi, in un semplice esempio, da soggetto, verbo, oggetto. Questi pattern aiutano molto quando si tenta di acquisire e tradurre significati tra forme diverse (ad esempio eventi e stato corrente)

Forse potresti dare un esempio di un evento che non ha un argomento e potremmo discuterne.

score 0 · Answer 2

Nel sourcing di eventi, gli eventi rappresentano in genere la cronologia di una o più entità (ad esempio, una cosa / un nome che ha identità e uno stato che cambia nel tempo). Per ricreare lo stato di un oggetto, riproduci la sua cronologia.

Quindi questa è l'idea giusta:

I thought about different solution. Instead of displaying processes display lower level events grouped by subject.

Like 'War 1 have started' and 'War 1 have ended' have the same subject - 'War 1' process.

Sostituisci "oggetto" con "identificatore univoco" e hai la giusta idea - tutti gli eventi che descrivono la storia di War 1 hanno lo stesso identificatore e possono essere usati per assemblare una proiezione (vista) di com'è la guerra in qualsiasi momento della storia.

Quindi quando il supereroe sorseggia il suo caffè, sta guardando un cruscotto che è stato costruito leggendo attraverso questi eventi; in questo caso, stai prendendo tutta la cronologia, identificando lo stato corrente di ciascuna delle guerre in esso, e scegliendo in base a quegli stati che cosa mostrare.

Quindi sotto le copertine potrebbe sembrare

Map<WarId,WarState> wars = new Map();
Set<WarId> interestingWars = new Set();

for(Event e : history.getEvents()) {
    WarState oldState = wars.get(e.warId);
    WarState newState = oldState.apply(e);
    wars.put(e.warId, newState);

    if (newState.isInteresting()) {
        interestingWars.add(e.warId);
    } else {
        interestingWars.remove(e.warId);
    }
}

for(WarId id : interestingWars) {
    display(wars.get(id));
}

'express event name as the verb in past tence not as noun'. So there could be no 'war' event. There could be only 'war started' and 'war ended' events. This clarify this a bit.

Sì, è molto importante - gli eventi descrivono cose che sono già accadute; non devi pensare se sono "permessi" o meno, semplicemente (in questo esempio) devi capire come presentare le informazioni.