(per una introduzione decisamente esaustiva a CQRS e Event Sourcing vi rimando all’articolo di Gianluca per UGIdotNET.)

In un mondo basato su CQRS ed Event Sourcing in cui tutto è pensato per poter scalare orizzontalmente (ne parleremo approfonditamente in un altro post) nulla vi impedisce di passare da un modello di questo genere:

Ad uno di questo genere:

o, per certi versi ancora peggio ma per moltissimi ancora meglio, ad uno di questo genere:

il problema

è molto sensato che il gestore dell’evento, quindi nel nostro esempio il de-normalizzatore, abbia bisogno di avere accesso al contesto di sicurezza che il comando portava con se, o in termini più tecnici abbia bisogno “far girare” il codice di de-normalizzazione con lo stesso utente che ha mandato il comando.

Nel primo esempio è naturale che ciò avvenga, se ad esempio siamo in un’applicazione web, il gestore dell’evento gira nello stesso thread della richiesta http e quindi HttpContext.Current.User è correttamente valorizzato come ci aspettiamo.

Negli altri due casi invece questo non è assolutamente vero, sempre prendendo come esempio un’applicazione web, un ipotetico thread in background non ha accesso al contesto della richiesta corrente, per il semplice fatto che un contesto potrebbe non esistere proprio in quel momento, cosa ancor più vera nel terzo esempio dove sono addirittura due processi diversi con una coda, con ad esempio il Service Bus di Azure, in mezzo.

La soluzione

Diventa a questo punto necessario che in ogni caso sia a carico nostro, quindi dell’infrastruttura, garantire che il contesto di sicurezza fluisca correttamente tra le varie componenti dell’architettura, in particolare ove questo fluire non è automatico.

Un esempio di tutto ciò lo potete trovate sul mio blog in inglese in relazione a Windows Identity Foundation e i messaggi gestiti con NServiceBus: http://milestone.topics.it/2012/06/ws-federation-on-top-of-nservicebus.html.

.m