6

część CRUD na bazie naszych potrzeb aplikacyjnych:Offline sync i wydarzenie pozyskiwania

  1. Offline dwukierunkowego „dwukierunkowy” synchronizowania
  2. możliwość modyfikowania danych, aż będą gotowe, a następnie „publikuje”.
  3. dziennik audytu

Event Sourcing (lub „wzór komenda”) jest to, czego szukam w celu osiągnięcia tych przedmiotów. Czuję się dobrze z rozwiązywaniem 2 & 3 z tym, ale nie jest jasne dla pierwszego elementu, synchronizacja.

Jeśli dla każdego polecenia są używane znaczniki czasu (jeśli jest to konieczne), czy polecenia trybu offline muszą być zastosowane do systemu głównego, tak jak byłyby w czasie rzeczywistym (połączone), lub czy mogę po prostu uznać je za zastosowane koniec dowolnego polecenia (z nowszym znacznikiem czasu)?

Pomocny byłby dowolny podstawowy opis algorytmu dla synchronizacji opartej na poleceniach.

+0

przydatnych artykułów dla mnie są http://touchlabblog.tumblr.com/post/33710233787/offline-sync-queue-aka-superbus i https://docs.google.com/file/d/0B_BG7hBPKUxaeVFTSUI4Ylp3VjQ/edit – Joel

Odpowiedz

9

będziemy chcieli sprawdzić, co Greg Młoda ma do powiedzenia o CQRS and Occasionally Connected Systems

Polecenia potrzebne do uruchomienia w systemie zapisu w momencie ich otrzymania. Tak więc klient offline może pracować z lokalnie buforowanymi, nieaktualnymi, kopią rekordu i kolejkami poleceń. Po ponownym podłączeniu klient aktualizuje swoją kopię systemu rekordów, uzgadnia kolejkowane polecenia z nowym stanem świata, a następnie wysyła nowe polecenia do systemu rekordu.

Dyskusja Grega przedstawia, w jaki sposób działa uzgodnienie dowodzenia (w zasadzie, patrząc na zdarzenia, które generują prowizoryczne polecenia, i szukając konfliktów z wydarzeniami zarejestrowanymi przez system rekordów). Dyskusja silnie sugeruje, że eksperci dziedzin będą chcieli, aby konflikty zdarzeń zostały rozwiązane w określony sposób.

+0

Właśnie tego szukam dzięki Tobie @VoiceOfUnreason –