* [ ] Разделить _development_, _release_ и _test_ зависимости
* [ ] Вынести части _ff_core_ в _genlib_
## Поддержка checkout
Каждая машина, на которую мы можем сослаться в рамках асинхронной операции, должно в идеале давать возможность _зафиксировать версию_ своего состояния посредством некой _ревизии_. Получение состояния по _ревизии_ осуществляется с помощью вызова операции _checkout_. В тривиальном случае _ревизия_ может быть выражена _меткой времени_, в идеале –_номером ревизии_.
Сервис должен давать возможность работать _нескольким_ клиентам, которые возможно не знают ничего друг о друге кроме того, что у них разные _tenant id_. В идеале _tenant_ должен иметь возможность давать знать осебе_динамически_, в рантайме, однако это довольно трудоёмкая задача. Если приводить аналогию с_Riak KV_, клиенты к нему могут: создать новый _bucket type_с необходимыми характеристиками, создать новый _bucket_с требуемыми параметрами N/R/W и так далее.
В итоге как будто бы не самая здравая идея. Есть ощущение, что проще и дешевле хранить и оперировать идентификаторами, и разыменовывать их каждый раз по необходимости.
## Служебные лимиты
Нужно уметь _ограничивать_ максимальное _ожидаемое_ количество тех или иных объектов, превышение которого может негативно влиять на качество обслуживания системы. Например, мы можем считать количество _выводов_ одним участником неограниченным, однако при этом неограниченное количество созданных _личностей_ мы совершенно не ожидаем. В этом случае возможно будет разумно ограничить их количество сверху труднодостижимой для подавляющего большинства планкой, например, в 1000 объектов. В идеале подобное должно быть точечно конфигурируемым.
