Comments 8
Хороший разбор, спасибо за статью.
По идее предполагается что экземпляр бизнес операции уникален в рамках бизнес процесса, как и сам экземпляр бизнес процесса.
Как будет обеспечиваться идентификация экземпляра бизнес операции - это одна проблема уровня доменной модели. Номер проводки, номер перевода, номер инвойса, комбинацией полей и т.д.
Как будет обеспечиваться единственный экземпляр\"singleton" и жизненный цикл операции - это другая проблема уровня физической модели и имплементации. Уникальный ключ отдельный, hash от набора данных операции или еще что-то..
Вопрос транспорта - это вообще третья проблема.
Хранить ключи вечно нельзя, значит есть окно.
Почему нельзя ? Зависит от дизайна системы. как будет оптимизироваться проверка уникальности - да, надо думать.
Исправьте форматирование кода. В этом невозможно разобраться.
Не имеет отношения к хабу Habr.
В платёжном контуре я бы отдельно развёл две проверки. Идемпотентность доказывает, что повтор не создал вторую операцию. Но она не доказывает, что первая операция дала приемлемый бизнес-результат: деньги могли списаться, а доступ или заказ остаться в промежуточном состоянии.
Как у вас устроен критерий сверки: он проверяет только эквивалентность состояния платёжного реестра при повторах или ещё и целевой пользовательский исход вместе с корректностью компенсации? И кто утверждает этот критерий: команда платёжного контура или независимый владелец бизнес-сценария?
Идемпотентность в платёжном конвейере: «повтори запрос» — это архитектура, а не retry