6

La parte CRUD a base delle nostre esigenze applicative:Offline sincronizzazione e l'evento di sourcing

  1. Offline bidirezionale "a due vie" sincronizzazione
  2. Possibilità di modificare i dati fino al momento e poi "pubblicare".
  3. Registro di controllo

evento Sourcing (o il "modello di comando") è quello che sto cercando di realizzare in questi elementi. Mi sento a mio agio a risolvere 2 & 3 con questo, ma non chiaro per l'articolo uno, la sincronizzazione.

Se per ogni comando vengono utilizzati timestamp (se necessario), i comandi offline devono essere applicati al sistema master come avrebbero dovuto essere in tempo reale (uniti), oppure posso considerarli applicati come accade a la fine di ogni comando (con un timestamp più recente)?

Qualsiasi descrizione di base dell'algoritmo per la sincronizzazione basata sui comandi sarebbe utile.

+0

Articoli utili per me sono http://touchlabblog.tumblr.com/post/33710233787/offline-sync-queue-aka-superbus e https://docs.google.com/file/d/0B_BG7hBPKUxaeVFTSUI4Ylp3VjQ/edit – Joel

risposta

9

ti consigliamo di rivedere ciò che Greg Young ha da dire circa CQRS and Occasionally Connected Systems

comandi devono eseguire sul sistema di record nel momento in cui vengono ricevuti. Così il tuo client offline può lavorare con il suo cache locale, stantio, copia del record e accodamento comandi. Una volta connesso nuovamente, il client aggiorna la sua copia del sistema di registrazione, riconcilia i suoi comandi in coda con il nuovo stato del mondo e quindi invia i nuovi comandi al sistema di registrazione.

Le parole di Greg illustrano come funzionava la riconciliazione dei comandi (in pratica, osservando gli eventi generati dai comandi provvisori e cercando i conflitti con gli eventi registrati dal sistema di registrazione). Il discorso implica che gli esperti di dominio vorranno risolvere i conflitti degli eventi in modi specifici.

+0

Questo è quello che sto cercando grazie a te @ VoiceOfUnreason –