# 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 объектов. В идеале подобное должно быть точечно конфигурируемым.