mirror of
https://github.com/valitydev/fistful-server.git
synced 2024-11-06 02:35:18 +00:00
7c7ad60e1b
* Drop (de)hydration for now, we'll think about it later. * Reduce boilerplate w/ the help of `ff_machine` though much to be done still. * Drop half-baked `ff_machine` from ff_core * Supply missing specs + fix marshalling types * Update test fixtures
52 lines
4.6 KiB
Markdown
52 lines
4.6 KiB
Markdown
# Fistful
|
||
|
||
> Wallet Processing Service
|
||
|
||
## Development plan
|
||
|
||
### Бизнес-функционал
|
||
|
||
* [x] Минимальный тестсьют для кошельков
|
||
* [x] Реализовать честный identity challenge
|
||
* [x] Запилить payment provider interface
|
||
* [ ] Запилить контактные данные личности
|
||
* [x] Запилить нормально трансферы
|
||
* [ ] Заворачивать изменения в единственный ивент в рамках операции
|
||
* [.] Компактизировать состояние сессий
|
||
* [ ] Запилить контроль лимитов по кошелькам
|
||
* [ ] Запилить авторизацию по активной идентификации
|
||
* [ ] Запилить отмену identity challenge
|
||
* [ ] Запускать выводы через оплату инвойса провайдеру выводов
|
||
* [ ] Обслуживать выводы по факту оплаты инвойса
|
||
|
||
### Корректность
|
||
|
||
* [.] Схема хранения моделей
|
||
* [ ] [Дегидратация](#дегидратация)
|
||
* [ ] [Поддержка checkout](#поддержка-checkout)
|
||
* [ ] [Коммуналка](#коммуналка)
|
||
|
||
### Удобство поддержки
|
||
|
||
* [ ] Добавить [служебные лимиты](#служебные-лимиты) в рамках одного party
|
||
* [ ] Добавить ручную прополку для всех асинхронных процессов
|
||
* [ ] Вынести _ff_withdraw_ в отдельный сервис
|
||
* [ ] Разделить _development_, _release_ и _test_ зависимости
|
||
* [ ] Вынести части _ff_core_ в _genlib_
|
||
|
||
## Поддержка checkout
|
||
|
||
Каждая машина, на которую мы можем сослаться в рамках асинхронной операции, должно в идеале давать возможность _зафиксировать версию_ своего состояния посредством некой _ревизии_. Получение состояния по _ревизии_ осуществляется с помощью вызова операции _checkout_. В тривиальном случае _ревизия_ может быть выражена _меткой времени_, в идеале – _номером ревизии_.
|
||
|
||
## Коммуналка
|
||
|
||
Сервис должен давать возможность работать _нескольким_ клиентам, которые возможно не знают ничего друг о друге кроме того, что у них разные _tenant id_. В идеале _tenant_ должен иметь возможность давать знать о себе _динамически_, в рантайме, однако это довольно трудоёмкая задача. Если приводить аналогию с _Riak KV_, клиенты к нему могут: создать новый _bucket type_ с необходимыми характеристиками, создать новый _bucket_ с требуемыми параметрами N/R/W и так далее.
|
||
|
||
## Дегидратация
|
||
|
||
В итоге как будто бы не самая здравая идея. Есть ощущение, что проще и дешевле хранить и оперировать идентификаторами, и разыменовывать их каждый раз по необходимости.
|
||
|
||
## Служебные лимиты
|
||
|
||
Нужно уметь _ограничивать_ максимальное _ожидаемое_ количество тех или иных объектов, превышение которого может негативно влиять на качество обслуживания системы. Например, мы можем считать количество _выводов_ одним участником неограниченным, однако при этом неограниченное количество созданных _личностей_ мы совершенно не ожидаем. В этом случае возможно будет разумно ограничить их количество сверху труднодостижимой для подавляющего большинства планкой, например, в 1000 объектов. В идеале подобное должно быть точечно конфигурируемым.
|