Gli eventi non riguardano ciò che è cambiato. Riguardano quando qualcosa è cambiato.

Posso creare un sistema di eventi completamente disaccoppiato dai contenuti che sono cambiati. In questo modo tutto ciò che apprendo da un evento è che un oggetto è stato aggiornato. Se mi interessa che l'oggetto sia stato aggiornato, allora dirò tutto ciò che sa come parlare a quell'oggetto per andare a chiederlo cosa è cambiato.

Questo non risolve il problema di comunicare queste modifiche. Impedisce semplicemente di diventare parte del sistema degli eventi.

Un esempio di un modo per risolvere il problema delle diverse versioni di dati è di fare in modo che l'osservatore crei e ponga l'oggetto osservato a una raccolta. L'oggetto osservato compila la raccolta con i suoi ultimi dati e quando il controllo ti restituisce (l'osservatore) ha ciò di cui hai bisogno. Se c'è qualcosa in più di cui non ti importa, perché non ne hai mai sentito parlare, semplicemente lo ignori.

Molti altri modi per dare una pelle a quel gatto, ma questo è uno di quelli in cui ho lavorato proprio in questo caso.

I framework come NServiceBus gestiscono questo utilizzando la versione dell'evento con la spedizione di messaggi polimorfici.

Ad esempio, la versione 1 del Servizio A potrebbe pubblicare un evento come IUserRegistered_v1. Quando Service A versione 1.1 deve includere un campo aggiuntivo, potrebbe dichiarare l'interfaccia IUserRegistered_v1_1, che erediterà da IUserRegistered_v1 e dichiarerà alcuni campi aggiuntivi.

Quando il Servizio A pubblica un evento IUserRegistered_v1_1, NServiceBus invierà il messaggio a tutti gli endpoint che gestiscono IUserRegistered_v1 o IUserRegistered_v1_1.

Miglioramento incrementale

Una semplice modifica al modello è che quando gli ascoltatori si registrano come osservatori, includono una lista o un'altra struttura degli elementi di dati che desiderano conoscere. Questo può funzionare se i dati restituiti dal servizio sono semplici, ma se hai una discreta quantità di dati gerarchici, questo può essere davvero complicato da implementare.

Rock-solida

Se vuoi davvero un modo robusto per fare questo progetto, il servizio in modo tale da mantenere una cronologia delle modifiche apportate ai dati che archivia. In sostanza, non si aggiornano mai i record nel proprio database, si aggiungono nuovi record in cui ognuno rappresenta la modifica. Ognuno di questi nuovi record è associato a un ID evento che identifica l'azione. Un record pari viene memorizzato con tutte le informazioni rilevanti sul cambiamento (chi, cosa, quando, ecc.) Questo ha alcuni altri vantaggi che sono al di fuori dello scopo di questa risposta, ma sono discussi in questo article sul teorema CAP .

Quando viene apportata una modifica, si crea il record dell'evento e si aggiungono tutti i nuovi dati al database. Quindi pubblichi un evento per gli ascoltatori che contiene (in minima parte) l'ID evento. Gli ascoltatori possono quindi richiedere i dati associati a tale ID e ottenere la versione dei dati ad essa associati. Ogni ascoltatore è quindi in grado di ottenere tutto ciò di cui ha bisogno senza accoppiare i bisogni di altri ascoltatori diversi insieme. Ti consiglio di aggiungere un sottogruppo dei campi dati più comunemente usati al messaggio dell'evento in modo che gli ascoltatori possano filtrare gli eventi a cui non sono interessati. Ciò può ridurre la chattiness del processo e alcuni ascoltatori potrebbero non aver mai bisogno di chiamare di nuovo a tutti. Questo ti protegge anche dai problemi di temporizzazione. Se si richiama semplicemente il servizio e si ottengono i dati in base alla chiave, potrebbero esserci altre modifiche tra il recupero dell'evento e il recupero dei dati. Questo potrebbe non essere importante per tutti gli ascoltatori ma può creare grossi problemi se è necessario conoscere tutte le modifiche. Il miglioramento incrementale del design di cui sopra è compatibile con questo approccio se si vuole davvero portarlo a 11.

Alcuni di questi possono essere esagerati per ciò che devi fare, ma secondo la mia esperienza se non hai un modo preciso per vedere come cambia un record nel tempo, alla fine tu o qualcuno che lavora con i tuoi dati vorrà .

@CandiedOrange fa un punto valido in un commento alla sua risposta relativa ai formati di dati estensibili come xml.

Non dovrebbe essere importante finché aggiungi dati. Fornire impostazioni predefinite sensibili per gli eventi precedenti / i campi non obbligatori, tuttavia.

Dovresti solo aggiornare i servizi che ti interessano - in questo caso - Sesso. Un parser xml / json dovrebbe essere in grado di ignorare dati extra per gli altri servizi. Questo dipende dalla scelta del parser e del formato dei dati degli eventi, naturalmente.

Non sono d'accordo con gli eventi che non hanno i dati rilevanti. Per il sourcing di eventi, gli eventi dovrebbero definire cosa è cambiato. Alla ricezione di un evento, altri servizi non dovrebbero dover recuperare i dati dall'origine dell'evento.