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

V>>С двумя покупателями проблемы нет, оба успешно купят товар, а запись в бд не их проблема, проблема с третьим и четвёртым покупателями. Один из них купит то, чего уже нет. Это нормальная ситуация в магазине. Тут надо просто выяснить у бизнеса, что делать с покупателем — увеличить срок доставки, вернуть деньги, что-то ещё. И запрограммировать именно то, чего ждёт бизнес, ублажение сервера бд всегда можно отложить на потом.
I>Проблема в том, в 9 сценариях из 10 можно проблемы избежать вообще в принципе — транзакционность решает.

Что увидит четвёртый покупатель? Товара нет и поэтому просто свалит в другой магазин? Проблема в том, что используя чисто техническое решение ты за бизнес решил как будет вести себя магазин в этой ситуации. Такие вещи должны быть отражены в коде явно, а не выводиться из особенностей использования системного софта типа сервера бд. Мы пишем приложения для бизнеса, а не плагины к бд.

Статья по ссылке имеет больше отношения к event sourcing. И это, кстати, подход, который автор темы может взять на вооружение: не учитывать оставшееся количество товара в одной записи бд, а иметь данные о складе и каждом заказе и каждой поставке товара покупателю, подсчитывая количество доступного товара со склада на ходу и не теряя заказов.

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

V>Что увидит четвёртый покупатель? Товара нет и поэтому просто свалит в другой магазин?
ПОкрутится ему "please wait", пока конкурентные транзакции завершатся и увидит то что есть на самом деле. Если бизнес не попросит показать ему что-нить другое.

V>Проблема в том, что используя чисто техническое решение ты за бизнес решил как будет вести себя магазин в этой ситуации. Такие вещи должны быть отражены в коде явно, а не выводиться из особенностей использования системного софта типа сервера бд. Мы пишем приложения для бизнеса, а не плагины к бд.
Проблема в том, что ты не понимаешь сути. Что технологии также влияют на бизнес(внезапно, а). Я уверен, что банкиры всего мира хотели бы иметь ACID гарантии по операциям с платежными картами, но это невозможно и выкручиваюся имея BASE и прописывая в договора такие приятные мелочи как неразрешенный овердрафт.
И если технология в конкретном бизнес кейсе, позволяет иметь консистентные данные в любой момент времени и атомарно их менять — то надо брать и использовать такую технологию в конкретном бизнес кейсе. Банально потому что так проще быстрей и дешевле. А что там покупателю показывать — можно разрулить бизнес кейсами, ет как раз несложно.

V>Статья по ссылке имеет больше отношения к event sourcing.
И что из этого следует?

V>И это, кстати, подход, который автор темы может взять на вооружение: не учитывать оставшееся количество товара в одной записи бд, а иметь данные о складе и каждом заказе и каждой поставке товара покупателю, подсчитывая количество доступного товара со склада на ходу и не теряя заказов.
Я рад за него. Он усложнил систему там где это совершенно не надо.
Программистам надо писать больше кода
Бизнесу надо будет придумывать ка обрабатывать ситуации с неконсистентными данными и как это обьяснять пользователям
У пользователей будут проблемы с недостоверной информацией на сайте.
А так — аффтар маладец!

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

V>Вот один способ решения проблемы на примере банка: http://blog.sapiensworks.com/post/2016/07/23/DDD-Eventual-Consistency

Все хотел отписать, руки не доходили. В этой статье прекрасно все. Но приведенный пример — это шедевр.

No computers, no CQRS, no EC. Or maybe…. Neah! John and Mary have a shared account at a local bank and it just happens that they decided to withdraw 100$ the same day. Unknowingly, they interact with different tellers, just a couple of minutes apart. Being an epoch without computers, for every operation needing to check an account’s balance the tellers need to talk to another clerk who’s in charge of maintaining the balances. At the moment T, the first teller goes and gets the account balance (it’s 100$). Then he starts to fill in the required paperwork, then handles John 100$. In the mean time, at T+2,the second teller (serving Mary) goes to the back-office clerk and gets the account’s balance. While he’s on the way back, teller #1 goes to tell the clerk that a transaction has occurred and the account balance needs to be updated. Teller #2 returns to Mary, handles the paperwork and gives her 100$. Then he goes to the clerk and tells him to register the new operation, thus updating the account balance.

John and Mary withdraw together 200$, from an account which only has 100$. When the clerk calculates the latest account balance, it gets a negative number. Dang! We have a problem!

Пример демонстрирует не только непонимание аффтора того, как работали банки, но и банально отсутсвие сколько нибудь критического восприятия действительности. Если бы банки работали по описанному сценарию, то они бы разорились прямо в зачаточном состоянии, во флоренции во времена позднего средневековья потому как хитрожопых товарищей во все времена было с избытком.
Дык от, аффтар наверное не в курсе, что в упомянутое позднее средневековье, уже придумали такие абстракции как "банковский счет", "бухгалтерская книга", "двойная запись" и т.д.
Дык от. Объект "счет" существовал физически в качестве записей в бухгалтерской книге. И он был один. И все изменения по нему проводились синхронно одним(отвественным!) человеком. Поэтому описанная ситуация попросту была попросту невозможно из-за синхронизации, присущей процессу изначально.

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

I>Дык от. Объект "счет" существовал физически в качестве записей в бухгалтерской книге. И он был один. И все изменения по нему проводились синхронно одним(отвественным!) человеком. Поэтому описанная ситуация попросту была попросту невозможно из-за синхронизации, присущей процессу изначально.

Кажется я понял как проектировали софт для Сбербанка.

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

V>Кажется я понял как проектировали софт для Сбербанка.

А причем тут софт для сбербанка? Просто хочется откаментить, но по сути сказать нечего?