Автономная синхронизация и поиск событий

Для CRUD-части нашего приложения требуется:

  1. Автономная двунаправленная «двусторонняя» синхронизация
  2. Возможность изменять данные до готовности, а затем «опубликовать».
  3. Журнал аудита

Источник событий (или «шаблон команды») — это то, что я ищу для выполнения этих задач. Я чувствую себя комфортно, решая 2 и 3 с этим, но не ясно для первого пункта, синхронизации.

Если для каждой команды используются временные метки (при необходимости), нужно ли применять автономные команды к основной системе, как если бы они выполнялись в режиме реального времени (объединенные), или я могу просто считать, что они применяются в конце любого команда (с более поздней отметкой времени)?

Было бы полезно любое базовое описание алгоритма для синхронизации на основе команд.


crud event-sourcing synchronization offline command-pattern
person Joel    schedule 11.02.2016    source источник
comment
Полезные статьи для меня: touchlabblog.tumblr.com/post/33710233787 / и docs.google.com/file/d/0B_BG7hBPKUxaeVFTSUI4Ylp3VjQ/edit< /а>   -  person Joel    schedule 12.02.2016

Ответы (1)


arrow_upward
21
arrow_downward

Вы захотите просмотреть, что Грег Янг говорит о CQRS и Периодически подключаемые системы

Команды должны выполняться в системе записи в момент их получения. Таким образом, ваш автономный клиент может работать с локально кэшированными, устаревшими, копиями записей и командами постановки в очередь. При повторном подключении клиент обновляет свою копию системы записи, согласовывает свои команды в очереди с новым состоянием мира, а затем отправляет новые команды в систему записи.

В докладе Грега показано, как работало согласование команд (в основном, путем просмотра событий, генерируемых предварительными командами, и поиска конфликтов с событиями, записанными системой записи). Выступление подразумевает, что эксперты в предметной области захотят, чтобы конфликты событий разрешались определенным образом.

person VoiceOfUnreason    schedule 19.02.2016
comment
Это то, что я ищу, спасибо тебе @VoiceOfUnreason - person Łukasz Woźniczka; 22.06.2017
comment
Одна проблема с простой проверкой конфликтов между предварительными событиями и событиями, полученными из системы записи, заключается в том, что она идентифицирует только команды, которые будут создавать такие конфликтующие события... но другие отложенные команды (которые сами по себе не создают конфликтующих событий) могут иметь некоторые причинно-следственная зависимость от такого конфликта, но это чрезвычайно сложно уловить, так как неизвестно, на какую информацию полагался пользователь, когда была дана команда. Итак, вы помечаете как (потенциально) не объединяемую каждую команду, которая была введена после первой конфликтующей команды? - person eggyal; 22.02.2021