Именно они и не нужны для проведения платежей. Вы видимо ни эту статью не читали, ни предыдущие. И в код не заглядывали, хотя ссылки есть. Не вижу смысла с вами спорить, потому что вы ожидаете определенный ход вещей, а все иное для вас по определению ошибка.
Речь идет о транзакции, которая запускается при работе с БД с целью выполнения запросов в рамках одного окна. Если происходит ошибка или иная проблема - все изменения откатываются.
Именно эти транзакции и не требуются для работы с финансовыми данными.
С и С++ не подходят для прикладных приложений. Я бы вообще уже постарался бы выводить их из использования, потому что они устарели по всем показателям.
Главная проблема С и С++ в том, что нужно быть мега-крутым, что бы что-то дельное писать, но что бы стать мега-крутым, надо кучу программ написать. И когда ты приложение напишешь - тебе никто не сможет сказать, что все работает правильно.
Но в целом с видосом согласен =) Поэтому и писал на Java изначально. Только нужно учитывать, что сервис проектировался таким образом, что у него есть ядро, которое можно написать один раз и больше не трогать - потому что не нужно.
Большая часть микросервисов такой фокус не провернет. Постоянно что-то менять надо. И менять много!
Делаете всем банкоматам, у которых есть лимит один кошелек. Делаете правило, что на баланс в этот кошелек нельзя переводить больше, чем Х рублей за период. Количество рпс значения не имеет. Все операции можно проводить параллельно.
Вариант 2, делаете специальный ресурс "лимит", который банкоматы "покупают". В этом случае у всех банкоматов может быть свой кошелек. Т.е. у вас будет контракт, состоящий из: 1. Перевод Х от клиента банкомату; 2. Банкомат покупает на Х лимитов с спец. кошелька; 3. Покупка у банкомата клиентом банкнот с серийниками, ну или если их нет - просто пишем, что "выдача наличных средств из банкомата YYY". Т.к. каждый ресурс (а деньги на балансе - это ресурс) нужно в начале подготовить к списанию, то ваш лимит выглядит вообще просто - обычный ресурс, каждый день ставите лимит в Х миллиардов рублей по cron-правилу и все. Наступило 00:00 и не важно, сколько сейчас лимит - делаете его Х млрд рублей. И подключаете ваши банкоматы, хоть все сразу на покупку лимитов у кошелька. Количество рпс значения не имеет от слова полностью. Если решите домашнее задание, то поймете, что упретесь в сетевые адаптеры и IOPS. В этой статье не просто так в домашнем задании сказано про резервирование товаров. Это универсальный алгоритм. Так же как и протокол общения с ресурсными подсистемами, такими как баланс - он универсальный.
И если в первом случае сделать лимит очень сложно (на самом деле сложно, лично я браться не буду за такое), то в случае с покупкой банкоматом лимита с какого-то спец. кошелька - это вообще легко и просто. И даже если по каким-то причинам банкомат деньги не выдаст, то просто отменим контракт, потому что банкомат не подтвердил выдачу (у контракта есть возможность сделать так, что бы стороны подтвердили, что можно завершать, когда все готово к процессу завершения). Но у вас вроде как есть "установка" на да или нет, так что вам явно не подходит более безопасный вариант.
И еще, про этот лимит вы мне сейчас говорите.
UPD: на самом деле можно даже ресурс "лимит" не создавать. Просто на кошельке держать деньги, которые могут быть переданы только банкоматам и больше никому. Система это прямо сейчас умеет. В этом случае даже усложнять ничего не придется. Оно просто будет работать.
UPD2: Для сервиса Баланс будет лучше, если лимит будет не устанавливаться в Х каждый день, а будут создаваться балансы заранее, в которых будет прописано, что АктивноС и АктивноДо - это с начала дня и до начала следующего дня. С точки зрения архитектуры сервиса Баланс, в т.ч. на данный момент это будет более правильным решением. Огромный +, что записи можно создавать заранее и не беспокоится, что что-то пройдет не так, а если и пойдет - сразу звать тех поддержку.
У налоговой в системе mireapay контроль еще выше, чем в текущей системе. Налоговая буквально является частью платежной системы и все проводимые платежи по идее должны проводиться с уплатой налогов сразу в налоговую, минуя всякие юрлица, т.е. покупая что-то - НДС сразу улетает в налоговую, переводя зп сотруднику - НДФЛ сразу вычисляется системой;
Контроль у государства в mireapay еще выше, чем есть сейчас, потому что можно не только контроллировать куда уходят деньги, но и кому и почему. Этому будет посвящена отдельная статья про СОРМ и в целом гос безопасность с секретностью;
Мошенникам будет еще сложнее, потому что если физ лицо получает деньги от множества других лиц (или сумма слишком большая, скажем больше 100 тыс), то полученные деньги могут быть "временно" заморожены и доложено куда надо, что бы разобрались. Деньги будут на счету у "мошенника", но забрать их можно будет в любой момент и вернуть потерпевшему, пока заморозка конкретных средств не пройдет. Причем работает это таким образом, что замораживается конкретная сумма, а не вообще весь счет. Даже если будет ложное срабатывание - людям жизнь это не испортит, свои деньги, которые у него до этого были - он сможет тратить как и раньше.
Уважаемый, правда, я вижу что вам в боль со мной общаться и вам сложно понять мои слова. Вы не читали мои статьи, особенно от 1 сентября, где все описано. Перечитайте, пожалуйста, мои статьи по mireapay. Вам яснее станет, что никаких мечтательством у меня и не пахнет в работе.
Банкомат - это просто "еще один кошелек", что бы выдать деньги мы можем передавать деньги на кошелек банкомата. Если успешно проходит - выдаем деньги. Тот кто стоит перед банкоматом деньги не получит, если у него на балансе нет нужной суммы и/или у банкомата нет нужных средств для выдачи - например не хватает банкнот или еще какой-либо мелочи. Причем при формировании таких запросов можно контроллировать такую штуку как "банкнотный ресурс" - потому что банкноты не являются "деньгами", это штуки, у которых есть серийник и от продажи чайников они никак не отличаются. Человек, который в банкомате снимает деньги для системы mireapay будет выглядеть как покупать банкнот с номерами 1,2,3,4. И это будет отражаться в контракте. Правда скорее всего для этого уже нужно будет банкоматы переделывать. Вряд ли серийники где-то хранятся в банкоматах сейчас и/или есть возможность у инкасаторов вводить такую информацию.
И это лишь один из вариантов решения. Если вас для принципиально, что банкомат - это тупая кнопка, то можно списывать деньги со счета клиента на какой-нибудь специальный счет. И потом система уже выдаст разрешение, что выдать деньги можно.
Но первый вариант мне кажется намного лучше, потому что у каждого банкомата будет свой цикл обработки и все что ему нужно будет - это дождаться завершения обработки контракта - считай разрешения, что можно выдать деньги или нет. Я уже не говорю про безопасность и аудит. На счете банкомата должен отражатся объем выданных средств. При начислении денег (клиент вносит сумму в банкомат) - банкомат переводит со своего счета на счет клиента - т.е. в явной форме еще и фиксируется откуда пришли деньги, потому что у каждого банкомата свой счет. Можно проводить аудит конкретного банкомата. Если удается - он завершает операцию, если нет - возвращает деньги. Если деньги вносит инкасатор - то деньги списываются в специальный счет - печатную машинку откуда деньги могут генерироваться в систему и который их и поглощает, цифры на этом счете можно рисовать любые, потому что это делает государство и ему без разницы какая сумма там будет, потому что эти деньги не существуют для экономики. Так как вся система контроллируется гос органами и только государство владеет узлами обработки, либо напрямую контроллируется специально обученным полковником - то это вполне нормально работает.
Вообще не очень понятно почему тема ушла в банкоматы, если это утилитарная вещь и ее реализовать можно многочисленными способами.
Причем эти два - это то что пришло в голову сразу. Существующие банкоматы, если я правильно понял ваши слова - вообще менять не надо, что бы они работали с mireapay. Сделать для них адаптер, который будет выполнять нужные команды - это вопрос 4-12 человеко-часов. Во всяком случае, если как вы говорите, ему надо сказать "да" или "нет".
Так же вы видимо забываете, что у меня нет заказчика и нет требований от него, что я обязан следовать требованиям "какого-то там регулятора с горы".
Что бы что-то требовать от меня, нужно для начала иметь влияние. А писать про "у нас оно работать так должно" - идите к тем, кто сидит на зарплате.
Если вы не способны мыслить за рамками вашего "загона", то пожалуйста, не тратьте хотя бы собственное время. Я уверен, что вы очень занятой человек, занимающий важную должность "где-то".
Этот разговор не стоит затрачиваемого вами времени.
Бизнес логика не зависит от языка реализации. Вы не можете сделать сложение двух чисел разными способами, отличающимися от языка к языку.
Вот если мы будем говорить про криптографию, векторные операции - тогда да. Джава не подходит, потому что не умеет, но обычные if-else программы работают одинаково везде. Ветвление не удастся сделать как-то иначе, чем это позволяет оборудование.
Но, если мы говорим про общий случай, когда речь идет о произвольной программе из всего множества возможных, тогда да, я с вами согласен, но речь шла не про общий случай в статье =)
Банкомат работает с сервисом контрактов, а не с отдельными компонентами платежной системы.
Вы же, что бы получить деньги в банке (представляете, так можно, прийти в кассу и снять деньги) - не идете к инкасатору с документами вместо кассира, что бы он вам отсыпал денег?
Еще раз повторяю. ЦБ и банки - это анахронизм и его давно пора убирать. Те государства, которые это своевременно не поймут - уйдут в историю. В mireapay ничего в номер счета не зашито и нет смысла этого делать.
Вы пытаетесь разговаривать со мной с точки зрения текущей инфраструктуры, которую автор и ставит своей целью упразднить и убрать.
И да, у меня есть способ, как мигрировать на новую инфраструктуру. Это не быстрый процесс, но реальный.
Счет - это совокупность балансов. У вас на счету может быть множество валют одновременно и при этом эти валюты сами могут быть типизированными, как ранее описывал.
Сервис контрактов следит за тем, что бы, если 100 рублей списали у Васи, то эти 100 рублей обязательно у кого-то оказались. Контракт не завершится, если сальдо с бульбой не сойдется. У кого-то -100, у кого-то +100. Иначе никак. Причем с соблюдением типа.
Сервис Баланс сделан целенаправленно именно таким, что работает с конкретным счетом и говорит о том, что он конкретно может по запросу сделать.
Приведу пример развернуто из того, что было выше:
Что бы перевести 100 рублей от Васи к Пете - сервис контрактов в начале попытается создать платеж у Васи, когда сервис Баланс скажет, что создал списание на 100 обычных рублей под идентификатором запроса Списание1, то сервис контрактов отправит запрос за зачисление 100 рублей Пете (мы не можем сразу же формировать зачисление, потому что не знаем вектор типа перечисляемых Пете рублей, у Васи могут быть маркированные рубли же, причем сам Вася о том, что его рубли меченные никогда не узнает, в будущем будет статья про СОРМ). Если сервис Баланс опять сообщит, что зачислить могу и жду подтверждения по идентификатору Зачисление1, тогда контракт переходит в стадию "Завершение". В этой стадии он уже не может быть отменен никем, даже системой, и отправляются подтверждения созданных ранее Списание1 и Зачисление1. В этот момент Петя получает свои деньги, а Вася получить обратно свои деньги уже не сможет, потому что контракты не отменяются и удалить их нельзя. Если он отправил деньги Пете по ошибке, то нужно создавать контракт на обратный перевод.
А теперь представь себе, что Вася живет в Москве, а Петя в Рио - о какой централизованной БД может идти речь?
Деньги в системе никуда не пропадают. Сервис Баланс - это подсистема большой системы и сами валюты - это один из ресурсов, которыми оперирует подсистема контрактов.
Вся платежная система строилась исходя из того, что будут центры в каждой области, плотность расположения узлов - в соответствии с нуждами экономики. Нет никакой централизации в проведении платежей у системы и она не нужна.
Это работает только при условиях: 1. Система не распределенная; 2. Все балансы одинаковые.
В сервисе Баланс все сущности типа баланс на данный момент величины векторные, приведу пример, есть рублевый баланс, но на них есть метка "Не для перевода заграницу", так же у вас есть рублевый баланс без ограничений, запишем их как (рубль,["Не для перевода заграницу"]) и (рубль,[]) соответственно. Эти балансы разные и их нельзя смешивать, это как разные типы. При попытке снять средства для оплаты зарубежной покупки - рубли с первого баланса недоступны.
Так же нужно учитывать, что сервис Баланс списывает деньги вникуда и зачисляет деньги изниоткуда. Куда уйдут деньги - решает сервис контрактов. Поэтому так важно, что бы сервис Баланс сообщил точно, какой тип средств он списал. Потому что разница между (рубль,["Не для перевода заграницу"]) и (рубль,[]) существенна.
В будущем, эта фича может быть использована для локализации денег в определенном контуре экономики государства. Например выдается кредит, льготный, фермеру на покупку оборудования, гсм и семян и только у отечесвенного производителя. На эти деньги он ничего кроме этих категорий купить не может. Он даже положить их на депозит не сможет, потому что это тоже "покупка", просто покупаешь в этом случае долг с типом "депозит". Когда эти деньги получит отечественный производитель, то он с ними идет "куда-то", где ему эти деньги меняют на что-то, что было обговорено заранее в рамках программы, все же такие вещи не делаются персонально под одного фермера.
В приведенном вами примере идет настолько существенное упрощение, что работать это будет только если есть некая центральная СУБД, куда все стекается, у каждого в ней есть счет и в итоге получаем ЦБ дубль 2. Не надо так.
Когда происходит создание платежа - средства резервируются. Они находятся на балансе, но другие процессы их получить не могут. Это то, как работает сервис Баланс сейчас и то, как он должен работать после выполнения домашнего задания.
Про бухгалтерскую терминологию ничего не знаю.
Если на пальцах:
У вас есть 1000 рублей. Если одновременно будет 11 списаний по 100 рублей, то 10 из них сообщат, что списать могут и ждут команду на подтверждение или отмену, и 11 скажет, что денег нет, но вы держитесь. Какой конкретно платеж будет одинадцатым - определить нельзя, любой из 11, при условии, что создавались одновременно.
Блокировки записей тут не происходит, блокируются значения, сами средства, поэтому и есть возможность не использовать транзакции БД или блокировку записей.
Про демонов вы еще CI/CD расскажите. Там сессия закончилась - будь добр выключиться. Никаких демонов.
Для успешного запуска вируса нужно всего лишь запускаться от рута. Дальше уже дело техники.
Нельзя просто так взять и скопировать чужую 3D модель.
Да, поправил. Спасибо. Видимо при копировании потерялось
Вот именно в предметной области вы и не разбираетесь, потому что не понимаете азов информатики. Изучите для началу теорию, потом возвращайтесь.
Именно они и не нужны для проведения платежей. Вы видимо ни эту статью не читали, ни предыдущие. И в код не заглядывали, хотя ссылки есть.
Не вижу смысла с вами спорить, потому что вы ожидаете определенный ход вещей, а все иное для вас по определению ошибка.
Речь идет о транзакции, которая запускается при работе с БД с целью выполнения запросов в рамках одного окна. Если происходит ошибка или иная проблема - все изменения откатываются.
Именно эти транзакции и не требуются для работы с финансовыми данными.
Есть и другие ЯП, компилируемые в исполняемые файлы. Некоторые даже используют тот же тулчейн, что и gcc.
С и С++ не подходят для прикладных приложений.
Я бы вообще уже постарался бы выводить их из использования, потому что они устарели по всем показателям.
Главная проблема С и С++ в том, что нужно быть мега-крутым, что бы что-то дельное писать, но что бы стать мега-крутым, надо кучу программ написать.
И когда ты приложение напишешь - тебе никто не сможет сказать, что все работает правильно.
Но в целом с видосом согласен =) Поэтому и писал на Java изначально.
Только нужно учитывать, что сервис проектировался таким образом, что у него есть ядро, которое можно написать один раз и больше не трогать - потому что не нужно.
Большая часть микросервисов такой фокус не провернет. Постоянно что-то менять надо. И менять много!
Это как раз предполагается. Вариант, что штекер вытащили и все рухнуло. Даже в этом случае все должно восстанавливаться.
Делаете всем банкоматам, у которых есть лимит один кошелек. Делаете правило, что на баланс в этот кошелек нельзя переводить больше, чем Х рублей за период.
Количество рпс значения не имеет. Все операции можно проводить параллельно.
Вариант 2, делаете специальный ресурс "лимит", который банкоматы "покупают". В этом случае у всех банкоматов может быть свой кошелек.
Т.е. у вас будет контракт, состоящий из:
1. Перевод Х от клиента банкомату;
2. Банкомат покупает на Х лимитов с спец. кошелька;
3. Покупка у банкомата клиентом банкнот с серийниками, ну или если их нет - просто пишем, что "выдача наличных средств из банкомата YYY".
Т.к. каждый ресурс (а деньги на балансе - это ресурс) нужно в начале подготовить к списанию, то ваш лимит выглядит вообще просто - обычный ресурс, каждый день ставите лимит в Х миллиардов рублей по cron-правилу и все. Наступило 00:00 и не важно, сколько сейчас лимит - делаете его Х млрд рублей. И подключаете ваши банкоматы, хоть все сразу на покупку лимитов у кошелька. Количество рпс значения не имеет от слова полностью. Если решите домашнее задание, то поймете, что упретесь в сетевые адаптеры и IOPS. В этой статье не просто так в домашнем задании сказано про резервирование товаров. Это универсальный алгоритм. Так же как и протокол общения с ресурсными подсистемами, такими как баланс - он универсальный.
И если в первом случае сделать лимит очень сложно (на самом деле сложно, лично я браться не буду за такое), то в случае с покупкой банкоматом лимита с какого-то спец. кошелька - это вообще легко и просто. И даже если по каким-то причинам банкомат деньги не выдаст, то просто отменим контракт, потому что банкомат не подтвердил выдачу (у контракта есть возможность сделать так, что бы стороны подтвердили, что можно завершать, когда все готово к процессу завершения). Но у вас вроде как есть "установка" на да или нет, так что вам явно не подходит более безопасный вариант.
И еще, про этот лимит вы мне сейчас говорите.
UPD: на самом деле можно даже ресурс "лимит" не создавать. Просто на кошельке держать деньги, которые могут быть переданы только банкоматам и больше никому. Система это прямо сейчас умеет. В этом случае даже усложнять ничего не придется. Оно просто будет работать.
UPD2: Для сервиса Баланс будет лучше, если лимит будет не устанавливаться в Х каждый день, а будут создаваться балансы заранее, в которых будет прописано, что АктивноС и АктивноДо - это с начала дня и до начала следующего дня. С точки зрения архитектуры сервиса Баланс, в т.ч. на данный момент это будет более правильным решением. Огромный +, что записи можно создавать заранее и не беспокоится, что что-то пройдет не так, а если и пойдет - сразу звать тех поддержку.
У налоговой в системе mireapay контроль еще выше, чем в текущей системе. Налоговая буквально является частью платежной системы и все проводимые платежи по идее должны проводиться с уплатой налогов сразу в налоговую, минуя всякие юрлица, т.е. покупая что-то - НДС сразу улетает в налоговую, переводя зп сотруднику - НДФЛ сразу вычисляется системой;
Контроль у государства в mireapay еще выше, чем есть сейчас, потому что можно не только контроллировать куда уходят деньги, но и кому и почему. Этому будет посвящена отдельная статья про СОРМ и в целом гос безопасность с секретностью;
Мошенникам будет еще сложнее, потому что если физ лицо получает деньги от множества других лиц (или сумма слишком большая, скажем больше 100 тыс), то полученные деньги могут быть "временно" заморожены и доложено куда надо, что бы разобрались. Деньги будут на счету у "мошенника", но забрать их можно будет в любой момент и вернуть потерпевшему, пока заморозка конкретных средств не пройдет. Причем работает это таким образом, что замораживается конкретная сумма, а не вообще весь счет. Даже если будет ложное срабатывание - людям жизнь это не испортит, свои деньги, которые у него до этого были - он сможет тратить как и раньше.
Уважаемый, правда, я вижу что вам в боль со мной общаться и вам сложно понять мои слова. Вы не читали мои статьи, особенно от 1 сентября, где все описано.
Перечитайте, пожалуйста, мои статьи по mireapay. Вам яснее станет, что никаких мечтательством у меня и не пахнет в работе.
Банкомат - это просто "еще один кошелек", что бы выдать деньги мы можем передавать деньги на кошелек банкомата. Если успешно проходит - выдаем деньги. Тот кто стоит перед банкоматом деньги не получит, если у него на балансе нет нужной суммы и/или у банкомата нет нужных средств для выдачи - например не хватает банкнот или еще какой-либо мелочи. Причем при формировании таких запросов можно контроллировать такую штуку как "банкнотный ресурс" - потому что банкноты не являются "деньгами", это штуки, у которых есть серийник и от продажи чайников они никак не отличаются. Человек, который в банкомате снимает деньги для системы mireapay будет выглядеть как покупать банкнот с номерами 1,2,3,4. И это будет отражаться в контракте. Правда скорее всего для этого уже нужно будет банкоматы переделывать. Вряд ли серийники где-то хранятся в банкоматах сейчас и/или есть возможность у инкасаторов вводить такую информацию.
И это лишь один из вариантов решения. Если вас для принципиально, что банкомат - это тупая кнопка, то можно списывать деньги со счета клиента на какой-нибудь специальный счет. И потом система уже выдаст разрешение, что выдать деньги можно.
Но первый вариант мне кажется намного лучше, потому что у каждого банкомата будет свой цикл обработки и все что ему нужно будет - это дождаться завершения обработки контракта - считай разрешения, что можно выдать деньги или нет. Я уже не говорю про безопасность и аудит. На счете банкомата должен отражатся объем выданных средств. При начислении денег (клиент вносит сумму в банкомат) - банкомат переводит со своего счета на счет клиента - т.е. в явной форме еще и фиксируется откуда пришли деньги, потому что у каждого банкомата свой счет. Можно проводить аудит конкретного банкомата. Если удается - он завершает операцию, если нет - возвращает деньги. Если деньги вносит инкасатор - то деньги списываются в специальный счет - печатную машинку откуда деньги могут генерироваться в систему и который их и поглощает, цифры на этом счете можно рисовать любые, потому что это делает государство и ему без разницы какая сумма там будет, потому что эти деньги не существуют для экономики. Так как вся система контроллируется гос органами и только государство владеет узлами обработки, либо напрямую контроллируется специально обученным полковником - то это вполне нормально работает.
Вообще не очень понятно почему тема ушла в банкоматы, если это утилитарная вещь и ее реализовать можно многочисленными способами.
Причем эти два - это то что пришло в голову сразу. Существующие банкоматы, если я правильно понял ваши слова - вообще менять не надо, что бы они работали с mireapay. Сделать для них адаптер, который будет выполнять нужные команды - это вопрос 4-12 человеко-часов. Во всяком случае, если как вы говорите, ему надо сказать "да" или "нет".
Так же вы видимо забываете, что у меня нет заказчика и нет требований от него, что я обязан следовать требованиям "какого-то там регулятора с горы".
Что бы что-то требовать от меня, нужно для начала иметь влияние. А писать про "у нас оно работать так должно" - идите к тем, кто сидит на зарплате.
Если вы не способны мыслить за рамками вашего "загона", то пожалуйста, не тратьте хотя бы собственное время. Я уверен, что вы очень занятой человек, занимающий важную должность "где-то".
Этот разговор не стоит затрачиваемого вами времени.
Бизнес логика не зависит от языка реализации. Вы не можете сделать сложение двух чисел разными способами, отличающимися от языка к языку.
Вот если мы будем говорить про криптографию, векторные операции - тогда да. Джава не подходит, потому что не умеет, но обычные if-else программы работают одинаково везде. Ветвление не удастся сделать как-то иначе, чем это позволяет оборудование.
Но, если мы говорим про общий случай, когда речь идет о произвольной программе из всего множества возможных, тогда да, я с вами согласен, но речь шла не про общий случай в статье =)
Банкомат работает с сервисом контрактов, а не с отдельными компонентами платежной системы.
Вы же, что бы получить деньги в банке (представляете, так можно, прийти в кассу и снять деньги) - не идете к инкасатору с документами вместо кассира, что бы он вам отсыпал денег?
Еще раз повторяю. ЦБ и банки - это анахронизм и его давно пора убирать. Те государства, которые это своевременно не поймут - уйдут в историю.
В mireapay ничего в номер счета не зашито и нет смысла этого делать.
Вы пытаетесь разговаривать со мной с точки зрения текущей инфраструктуры, которую автор и ставит своей целью упразднить и убрать.
И да, у меня есть способ, как мигрировать на новую инфраструктуру. Это не быстрый процесс, но реальный.
Счет - это совокупность балансов. У вас на счету может быть множество валют одновременно и при этом эти валюты сами могут быть типизированными, как ранее описывал.
Сервис контрактов следит за тем, что бы, если 100 рублей списали у Васи, то эти 100 рублей обязательно у кого-то оказались.
Контракт не завершится, если сальдо с бульбой не сойдется. У кого-то -100, у кого-то +100. Иначе никак. Причем с соблюдением типа.
Сервис Баланс сделан целенаправленно именно таким, что работает с конкретным счетом и говорит о том, что он конкретно может по запросу сделать.
Приведу пример развернуто из того, что было выше:
Что бы перевести 100 рублей от Васи к Пете - сервис контрактов в начале попытается создать платеж у Васи, когда сервис Баланс скажет, что создал списание на 100 обычных рублей под идентификатором запроса Списание1, то сервис контрактов отправит запрос за зачисление 100 рублей Пете (мы не можем сразу же формировать зачисление, потому что не знаем вектор типа перечисляемых Пете рублей, у Васи могут быть маркированные рубли же, причем сам Вася о том, что его рубли меченные никогда не узнает, в будущем будет статья про СОРМ). Если сервис Баланс опять сообщит, что зачислить могу и жду подтверждения по идентификатору Зачисление1, тогда контракт переходит в стадию "Завершение". В этой стадии он уже не может быть отменен никем, даже системой, и отправляются подтверждения созданных ранее Списание1 и Зачисление1. В этот момент Петя получает свои деньги, а Вася получить обратно свои деньги уже не сможет, потому что контракты не отменяются и удалить их нельзя.
Если он отправил деньги Пете по ошибке, то нужно создавать контракт на обратный перевод.
А теперь представь себе, что Вася живет в Москве, а Петя в Рио - о какой централизованной БД может идти речь?
Деньги в системе никуда не пропадают.
Сервис Баланс - это подсистема большой системы и сами валюты - это один из ресурсов, которыми оперирует подсистема контрактов.
Вся платежная система строилась исходя из того, что будут центры в каждой области, плотность расположения узлов - в соответствии с нуждами экономики. Нет никакой централизации в проведении платежей у системы и она не нужна.
Это работает только при условиях:
1. Система не распределенная;
2. Все балансы одинаковые.
В сервисе Баланс все сущности типа баланс на данный момент величины векторные, приведу пример, есть рублевый баланс, но на них есть метка "Не для перевода заграницу", так же у вас есть рублевый баланс без ограничений, запишем их как (рубль,["Не для перевода заграницу"]) и (рубль,[]) соответственно. Эти балансы разные и их нельзя смешивать, это как разные типы. При попытке снять средства для оплаты зарубежной покупки - рубли с первого баланса недоступны.
Так же нужно учитывать, что сервис Баланс списывает деньги вникуда и зачисляет деньги изниоткуда. Куда уйдут деньги - решает сервис контрактов. Поэтому так важно, что бы сервис Баланс сообщил точно, какой тип средств он списал. Потому что разница между (рубль,["Не для перевода заграницу"]) и (рубль,[]) существенна.
В будущем, эта фича может быть использована для локализации денег в определенном контуре экономики государства. Например выдается кредит, льготный, фермеру на покупку оборудования, гсм и семян и только у отечесвенного производителя. На эти деньги он ничего кроме этих категорий купить не может. Он даже положить их на депозит не сможет, потому что это тоже "покупка", просто покупаешь в этом случае долг с типом "депозит".
Когда эти деньги получит отечественный производитель, то он с ними идет "куда-то", где ему эти деньги меняют на что-то, что было обговорено заранее в рамках программы, все же такие вещи не делаются персонально под одного фермера.
В приведенном вами примере идет настолько существенное упрощение, что работать это будет только если есть некая центральная СУБД, куда все стекается, у каждого в ней есть счет и в итоге получаем ЦБ дубль 2. Не надо так.
Когда происходит создание платежа - средства резервируются. Они находятся на балансе, но другие процессы их получить не могут. Это то, как работает сервис Баланс сейчас и то, как он должен работать после выполнения домашнего задания.
Про бухгалтерскую терминологию ничего не знаю.
Если на пальцах:
У вас есть 1000 рублей. Если одновременно будет 11 списаний по 100 рублей, то 10 из них сообщат, что списать могут и ждут команду на подтверждение или отмену, и 11 скажет, что денег нет, но вы держитесь. Какой конкретно платеж будет одинадцатым - определить нельзя, любой из 11, при условии, что создавались одновременно.
Блокировки записей тут не происходит, блокируются значения, сами средства, поэтому и есть возможность не использовать транзакции БД или блокировку записей.