У меня есть система Event Sourcing & async CQRS.Мы поддерживаем реальный процесс, такой как:
- Пользователю назначается задача, содержащая элементы X.
- Когда пользователь завершает элементы, он отправляет команды в систему для изменения элемента.государство.
- Когда пользователь завершает работу, он отправляет команду, чтобы закрыть задачу.Им разрешено делать это, даже если все предметы не были завершены.
- Менеджер по сагам / процессам реагирует на событие закрытия задачи и создает новые задачи, содержащие элементы, которые не были выполнены пользователем.
Поскольку наша сага выпускаетсякоманды, основанные на том, какие элементы не были выполнены, мы думали, что важно не обрабатывать команду закрытия задачи (и создавать событие закрытия задачи, на которое саги будет реагировать), пока все команды завершения элемента не будут обработаны.
Для этого мы реализовали последовательность команд.Где пользовательское приложение дает каждой команде инкрементный идентификатор.Идентификаторы ограничены, чтобы преподавать задачу.Таким образом, первая команда для каждой задачи начинается с команды 0. Когда наш домен пытается обработать команду, у которой нет ожидаемого следующего порядкового номера для задачи, мы выдаем исключение, и команда повторяется позже (она помещается сзадиочереди сообщений).
Это работает в разработке, но у меня есть опасения по поводу запуска этой схемы в производстве.Мои опасения двояки:
1) Мы зависим от пользовательского приложения, чтобы обеспечить правильные порядковые номера для команд.В настоящее время пользователям разрешено менять устройства во время работы над задачей, и мы уже определили некоторые крайние случаи, когда переключение устройства может привести к тому, что порядковые номера команд будут неправильными, когда пользователь переключается на новое устройство, прежде чем можно будет прочитать обновленные модели.
2) Если мы потеряем команду или не сможем ее обработать, по любой причине мы будем мягко блокировать задачу.Поскольку ожидаемый порядковый номер доменной модели задачи никогда не получит пакет с номером отсутствующей или непроцессируемой команды.
Я видел, что упорядочение является нормальным подходом в системах ES CQRS, которые имеют ограничения порядка.Но обнаруженные мной глубокие погружения обычно говорят о проблемах модели чтения, а порядковые номера генерируются доменом во время обработки команд и отслеживаются события.В нашем случае мы вообще не хотим обрабатывать команду закрытия задачи, если будущие команды будут приходить для одной и той же задачи.
У меня такой вопрос: я не прав, рассматривая последовательность команд, как у нас?Реализовано ли это «опасно» в производственной системе?И если да, то есть ли лучшая практика для таких требований, как у нас?