Здравствуйте, ·, Вы писали:

·>Здравствуйте, gandjustas, Вы писали:

G>>Там много обсуждали разные задачи и конкретно этот кейс про задачу, которая может быть решена в рамках одной транзакции БД.
G>>Или вы хотите сказать что вообще не надо опираться на транзакции БД потому что бывают бизнес-процессы, которые не укладываются в транзакции БД?
·>Так ведь вопрос идёт об архитектуре. Откуда так получилось, что разные независимые физические сущности оказались в одной БД? Склад, корзина пользователя, каталоги товаров — всё лежит в одном монолите... Удобно, конечно, но работает плохо, т.к. неверно моделирует реальность.
А в чем смысл "верно моделировать реальность"? тем более что у слов "верно" и "реальность" очень субъективное понимание?
Я думаю есть единственно верный способ моделирования — отталкиваться от конкретных решаемых задач. Если нам нужно транзакционно обновить состояние корзины с резервов на складе, то они должны быть в одной базе и работать в одной транзакции.

G>>·>Это не в рамках МСА, а в реальном физическом мире не бывает атомарности. МСА это делает очевидным и заставляет выражать явно.
G>>В рамках одного процесса вполне себе бывает.
·>Ну вот плохо получается, если моделировать одним процессом.
Тогда можно атомарность сделать за счет одной бд на одном сервере.
СУБД умеет обеспечивать атомарность изменений в рамках одного сервера\бд. Прям гарантировано умеет, в отличие от наколеночных поделок.

·>Участники бизнес-процессов в реальном мире — независимы, географически распределены, работают параллельно.
Как это связано? Если они все приходят в итоге на одни сервер? бд например, то задача решаема.

G>>>>И самое главное сможете ли вы с этим жить в будущем.
G>>·>Хошь, не хошь, а придётся.
G>>Угу, ровно до тех пор пока не появятся требования чтобы этого не было.
·>Законы физики требованиями не изменишь.
Так ты архитектуру подстраивай под физику, а не требования под архитектуру. Архитектура это вообще наименее ценное что у тебя есть в проекте.

G>>·>И нам придётся писать извинительное письмо "счастливому" клиенту, оплатить курьеру потраченное время и бензин, откатить платёж по кредитке, оплатив banking fees.
G>>·>Вот такой он, откат атомарной транзакции.
G>>Тут дело не в транзакции выдачи со склада, тут вы транзакционность потеряли парой шагов бизнес-процесса ранее.
·>Это разные транзакции в разных частях системы.
И что? Все равно потеряли.
В рамках бизес-процесса бывают шаги, где нужна транзакционно, а бывает что не нужна. Я же описывал что резервирование товаров на складе и смена статуса заказа на "зарезервирован" должны быть в одной транзакции, также как и уменьшение остатков на складе при смене статуса на "отгружен". А вот между этими двумя шагами никакая транзакционность не нужна.

G>>·>А как ты себе представляешь перевести огромную систему над которой работают десятки-сотни девов с одной версии на другую? У разных частей системы могут быть разные требования к памяти-процу-сети-диску.
G>>Ну для команды в 25 человек я делал, ничего катастрофичного, тем более зачастую есть обратная совместимость.
G>>Но я не знаю проблемы конкретно жабы, что там за проблема перехода с версии на версию.
·>В мелкомасштабных проектах работает, да. А так банально даже не в версии дело, а скажем, есть Azul и Oracle. С разной стоимостью, лицензиями и разными свойствами. Да даже просто ключи запуска могут отличаться.
И это повод не пользоваться транзакциями?

G>>У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.
·>Именно. А начнёшь переезд — заколебаешься для большого проекта.
Так у меня большой проект. За 10 лет огого сколько всего написали.