Go to file
2018-07-03 18:40:16 +03:00
apps [WIP] Give some missing specs on ct_domain 2018-07-03 17:38:45 +03:00
build-utils@f7fe66c9f3 wip 2018-06-13 16:43:48 +03:00
config [WIP] Expand provider / class / level definitions 2018-06-21 20:02:37 +03:00
test [WIP] Test identity challenge (actually, not) 2018-07-02 18:44:36 +03:00
.gitignore [WIP] Ignore test logs 2018-06-20 16:20:39 +03:00
.gitmodules wip 2018-06-13 16:43:48 +03:00
docker-compose.sh [WIP] Initialize cds keyring before running any tests 2018-07-02 20:24:44 +03:00
Dockerfile.sh wip 2018-06-13 16:43:48 +03:00
elvis.config wip 2018-06-13 16:43:48 +03:00
Jenkinsfile wip 2018-06-13 16:43:48 +03:00
Makefile [WIP] Add make shortcut to run specific test suite 2018-07-03 18:40:16 +03:00
README.md [WIP] Add TODO note on multitenancy 2018-07-02 18:42:54 +03:00
rebar.config [WIP] Test identity challenge (actually, not) 2018-07-02 18:44:36 +03:00
rebar.lock [WIP] Switch to epic in rbkmoney/identification-proto 2018-06-25 17:55:13 +03:00

Fistful

Wallet Processing Service

Development plan

Бизнес-функционал

  • Минимальный тестсьют для кошельков
  • Реализовать честный identity challenge
  • Запилить payment provider interface
  • Запилить контроль лимитов по кошелькам
  • Запускать выводы через оплату инвойса провайдеру выводов
  • Обслуживать выводы по факту оплаты инвойса

Корректность

Удобство поддержки

  • Вынести ff_withdraw в отдельный сервис
  • Разделить development, release и test зависимости
  • Вынести части ff_core в genlib

Поддержка checkout

Каждая машина, на которую мы можем сослаться в рамках асинхронной операции, должно в идеале давать возможность зафиксировать версию своего состояния посредством некой ревизии. Получение состояния по ревизии осуществляется с помощью вызова операции checkout. В тривиальном случае ревизия может быть выражена меткой времени, в идеале номером ревизии.

Коммуналка

Сервис должен давать возможность работать нескольким клиентам, которые возможно не знают ничего друг о друге кроме того, что у них разные tenant id. В идеале tenant должен иметь возможность давать знать о себе динамически, в рантайме, однако это довольно трудоёмкая задача. Если приводить аналогию с Riak KV, клиенты к нему могут: создать новый bucket type с необходимыми характеристиками, создать новый bucket с требуемыми параметрами N/R/W и так далее.