Я новичок в поиске событий, но для нашего текущего проекта я считаю его очень перспективным вариантом, в основном из-за аудита.
Одна вещь, которой я не на 100% доволен, это отсутствие совокупных транскаций. Пожалуйста, рассмотрите следующую проблему:
У меня есть заказ , который обрабатывается на разных станциях на разных станциях. И у нас есть контейнеры , где работники помещают заказ и переносят его с машины на машину.
Отслеживание должно выполняться через контейнеры ( с уникальным штрих-кодом), заказ не может быть идентифицирован. Проблема в том, что контейнеры используются повторно и должны быть заблокированы, поэтому ни один работник не может поместить два ордера в один и тот же контейнер одновременно (для простоты) просто предположим, что они не могут видеть, есть ли уже заказ внутри контейнера).
Для ясности, высокоуровневое представление:
- Заказ A создан
- Заказ Поставка на контейнер 1
- Контейнер 1 перемещается на машину A и сканируется
- Машина A генерирует некоторые события для заказа A
- перемещение заказ A из контейнер 1 до контейнер 2
- Заказ B создан
- Заказ B надет Контейнер 1 ...
"Move Order A от Контейнер 1 до Контейнер 2 "- это то, с чем я борюсь.
Это то, что должно происходить в транзакции (которой не существует) :
- Контейнер 2 : LockAquiredEvent
- Порядок A : PositionChangedEvent
- Контейнер 1 : LockReleasedEvent
Если приложение падает после позиции 1 или позиция 2, у нас есть контейнеры, которые заблокированы и не могут быть повторно использованы.
Я имею в виду несколько возможных решений, но я не уверен, что есть более элегантное:
- Предположим, что он не будет выходить из строя чаще, чем раз в неделю, и предоставьте способ, которым работники могут вручную исправить это.
- Рассматривайте отслеживание контейнеров как другой домен и не используйте поиск событий в этом domain.
- Реализация саги с компенсационными действиями и прочим.
Есть ли что-нибудь еще, что я могу сделать?
Я думаю, что сага - это путь к go, но у нас будет API для отдыха, где мы получим команду порядок передачи A из контейнера 1 в 2 , и это будет означать, что обработчику команд API потребуется прослушивать поток событий и ждать какое-то сагарное событие для доставки 200 запрашивающей стороне. Я не думаю, что это хороший дизайн, не так ли?
Не использование источников для отслеживания событий также не идеально, потому что контейнеры могут влиять на качество заказа, поэтому заказ должен отслеживать подержанные контейнеры тоже.
Спасибо за любые подсказки.