Именно для этого нужны оптимистичные или писсимистичные локи.

кейс с заказами и позициями заказа - вполне жизненный - но я не понял : какая именно реализация этого кейса не правильная, а какая по феншую

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

я может что то пропустил, но вроде речь шла про обьекты - а потом раз и про реализацию в персистентном хранилище

Это пример связи объектов просто первый в голову пришёл. Вы уже говорите о eventually consistentsy. Тоесть вы признали что облажались с консистентностью в приложении.
В Европе не обязан. Можно в последний момент сказать упс цена другая продать не можем.

Оптимистик лок на уровне объектов впринципе но да согласен.
Я про целостность данных.

Я же предлагаю сразу делать так что мгновенная констстентность на уровне агрегата и между ними eventual. Помогает увидеть проблемы и факапы в зародыше подобные. А там где нет логики и конкурентности простые круды напрямую в базу с каким нить app sync или hasura

локом  мы как раз таки лишаем себя изменению цены, нет?

Как мы ответим упс

Да. Но надо держать в уме все связи и лочить их на чтение. Кто то что то добавил и забыл лок во всех местах проставить и всё похеряно. Вы так нафиг базу убьёте с такими количеством локов на чтение. Даже оптимистик лок не выйдет.

Ну просто говорим заказ не создался ибо цена другая.

вот есть три разных типа истории : бизнесовая - это вот про эти риски с изменениями цен, про то кто несет издержки и характеристики излержек - во время агрегаторов - часто цена на условном я.маркете и 1с конкретного поставщика будут эээ ... разными - и это дело бизнес выработать правила, вторая история как работать с отражением объектов реального мира   в коде, а третья история как хранить состояние обьектов в персистентном хранилище.

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

Это про объекты. Именно про обекты. Прошу не путать пхп объекты и объекты. Не каждый пхп объект является объектом.

Ну да всё связано и проектируется под требования бизнеса. Особенно под то где ему надо моментальную согласованность а где итоговую. Ну и чем меньше агрегаты/объекты и чем их меньше тем лучше. Ибо границы транзакций и локов меньше.

тогда формализуйте то что вы называете объектом (или дайте ссылку на источник - который отражает ваше представление )- и уточните в чем проблема использования ссылки на другой объект - через конкретный пример. Так как речь не про бизнесовую часть, и не про реализацию сохранения состояния в конкретном персистентном хранилище - то укажите проблематику в разрезе именно работы с связями  обьектов на уровне реализации в  языке программирования

я что-то не знаю, или понять не могу... Но одно поняла точно, что все же "надо держать в уме все связи" )))

Проблема в том что подобное происходит при наличии любой связи. Но люди об этом даже не задумываются и никак не берут в расчёт.

Зачем нужны локи вы знаете?

не, вообще о каких локах речь ))