но в этом случае непосредственно перед созданием/изменением проверяются эти условия

Так вы проверяете по устаревшим данным. К примеру станете ли вы доверять проверке если данные которые вы используете устарли На месяц? На час? На минуту? На миллисекунду? На наносекунду?

хендлер зависнет на час?  На миллисекунду допускаю, но и различные доки (чеки, акты, счета) не расчитаны на миллисекунду, в реальном мире нет такого

А на 5 минут? Например если реплика отстала из-за нагрузки?

Почему нет? Представьте олимпийский стадион где место на трибуне хотят купить 1500 человек/ ботов в раз. И там просто 100 транзакций в очереди могут стоять и исполнятся каждую микросекунду

Или вот пользователь покупает и в то же время система его банит за фрод. В итоге он купил в то время пока был забанен.

ну если встанет кейс на милисекунды для олимпийцев, без проблем, и только на время создания

т.е прям вот запрос и сразу в базу ?

вот тут интересный кейс, что должны лочить? Пользователя или заказ? ))

Почему это не может произойти в вашей системе что несколько человек или систем решили воспользоваться и поменять данные одновременно? Вы просто говорите себе что это редкий случай и в случае факапа не страшно? Или просто не задумыаетесь об этом и не сообщая бизнесу о возможности редкой такой проблемы?

как вот все это живет в реалиях когда складские остатки в 1с живут, у сайта своя бд?

нет, просто в реальности эти кейсы единичны

Тут от бизнеса зависит. Но а целом просто один и тот же агрегат участвует в обоих процессах если надо мгновенную согласованность. А агрегат всегда только в один "поток" работает. Или просто приходим к итоговой согласованности с компенсационными действиями.

согласна, когда консистентность данных зависит еще от кучи сервисов, то без вариантов

Тут надо или в 1с делать или сразу продумывать компенсационные действия для итоговой согласованости

ну вот человек оформил заказ, на сайте, есть 1с - ка в которой живут складские остатки - и счастье если нет несколько филиалов где свои 1с- ки, а потом вот клиент начал картой платить - вот на этом этапе пока он платит - для согласованности данных вы что лочить то будете ?))

Ну вот вы сказали своему бизнесу что вы ему единично можете покоцать данные? Наверно бывает всплывают баги которые сами лечатся но иногда проскакивают. По моему опыту с этим связано много.

Я вот такое поведение не люблю как разработчик ну и бизнесу говорю если не смогу дать гарантии консистентности и спрашиваю что делать когда она нарушиться. И хотябы это логирую.

В вашем случае об этом ни кто не знает и не узнает.

приятная беседа, я оф, всем доброй ночи!

Нет ибо не возможно.
Надо обсуждать с бизнесом что делать когда прожали то чего нет. Как вы компенсировать это будете. Пока вы не владеете и не контролируете остатки других вариантов нет.
Хотя можно еще сделать холд. Сказать ваш заказ в процессе создания. Сходить во все системы взять что надо убедиться что есть. Если есть холд удержать если нет осврбодить.
Послать клиенту письмо успешно или нет заказ создался.
Это тоже итоговая согласованность. Но бизнесу обречено не нравится ибо надо быстро. Проще им сразу сказать что всё хорошо а в случае если нет откупиться

Так немного поменялось)

protected function setUp(): void
   {
       $this->client = static::createClient();
       $this->client->disableReboot();
       $this->em = static::getContainer()->get('doctrine')->getManager();
}

public function test_userinfo_success()
       $userRepository = $this->em->getRepository(User::class);
       $testUser = $userRepository->findOneBy(['email' => 'black.jack@mail.ru']);
       $this->client->loginUser($testUser);
}

You have requested a non-existent service "security.untracked_token_storage"

хз, возможно провайдер не описан в сесуриту ямл на сущность юзера