SP
всегда есть способ
Size: a a a
2021 August 02
PD
Это я тоже прекрасно понимаю. И понимаю что везде транзакционность не сделать.
PD
Вот в моем случае это занимает 100% пользователей, как и у какого-нибудь Mastercard по идее )
PD
Ладно, мы кажется начинаем куда-то забуриваться не туда.
Основное что тут полезное - использовать двойную запись.
Остальное уже технические больше нюансы которые зависят от кейсов
Основное что тут полезное - использовать двойную запись.
Остальное уже технические больше нюансы которые зависят от кейсов
SP
ну то есть у тебя 100% пользователей мошенники?
PD
Потенциальные мошенники, и на основе статистики и рулов уже в моменте решается что-то.
Потенциальные кейсы:
1) Угоны карт
2) Отмывание денег
Потенциальные кейсы:
1) Угоны карт
2) Отмывание денег
VS
плюс ко всему, сто процентной консистентности по бизнес-транзакции в реальности не существует
https://www.youtube.com/watch?v=VznZcQJQ_C0
https://www.youtube.com/watch?v=VznZcQJQ_C0
PD
Самое то что смешное, что эти все проверки в основном нужны для того, чтоб быть Compliant с регуляторикой. В моем кейсе 🙂
SP
мне все еще нравится кейс Альберто про "попробуйте атомарно произвести транзакцию покупки хотдога"
PD
Атомарность тут ломается на границе со внешними системами, это нормально. Но это не значит что атомарности теперь нет нигде. Крайности получаются, разве нет?
SP
какие внешние системы, речь идет о том что в одной руке у тебя деньги а в другой хотдог и вы атомарно проивзодите обмен
SP
в реальности ты платишь деньги и чел может с ними убежать и не будет у тебя хотдога, или ты можешь получить хотдог и потребовать деньги назад и т.д.
PD
Две внешние системы, человек с карточкой, и магазин с товаром. Один в один же.
SP
короч - SQL это отличная штука не для атомарно консистентно (если у тебя конечно логика не в БД) а для аналитики и тд. А лог транзакций для твоей любимой двойной записи можно спокойно и красиво держать в той же динаме
SP
nosql тоже атомарность тебе в пределах документа или коллекции могут гарантировать, так что сравнивать эти вещи в таком ключе не совсем корректно
SP
p.s. я по дефолту беру postgresql просто потому что универсально выходит но не идеально для всех кейсов.
ГС
Есть сущность User его login должен быть уникален среди всех юзеров. Есть метод user.changeLogin() который меняет его. Как правильно проверить уникальность логина? Из сущности вызывать метод репозитория isUse()? Или написать сервис и перенести changeLogin туда?
SP
Никак. Повесить констрейнт в базе и не париться.
SP
В худшем случае отдельно в сервисе проверить просто никаких гарантий такая проверка не даёт. У тебя на ui с большим успехом будет уменьшаться вероятность конфликта
SP
Не та фича где стоит делать сложно