## Модуль application перегружен и переусложнён

Предлагаю превратить этот модуль в группу модулей, как `common` - это раз, - и два: вынести поля заявки, которые мы заполняем в разделе `/application`, в отдельную сущность. Структура видится мне так:

*application.core*

Здесь живёт модель заяки (та, у которой статус, сумма, срок). Именно в `application/core` хотят другие модули, когда хотят узнать, что там с заявкой текущего пользователя.

*application.statement*

Здесь живёт та злоебучая анкета, которую мы заполняем в разделе `/applicaion`. В эту сущность переезжают все `passportNumber` и прочие `familySize`. Здесь же лежит функционал по загрузке этой гигантской модели на сервер и скачивания с него оной.

*application.contacts*

Содержит форму контактных данных пользователя. Кстати, для упрощения. Все формы из раздела заявки можно научить принимать вместо `initialValues` модель из `application.statement` (`Partial<Model>`) и её же отдавать в `onSubmit`. Таким образом мы сможет отдать маппинг "форма - модель" и "модель - форма" на откуп самой форме (сейчас это делает злоебучий `FormHelper` и он мне пиздец как не нравится, хотя я его и написал. Писал с ненавистью, так сказать).

Итого: формы смотрят в Statement Store, чтобы отрисоваться, туда же бросает свои изменения на onSubmit.

*application.passport*

Содержит форму паспортных данных.

*application.residence*

Сюда переезжает форма с адресами юзера.

*application.family*

Помимо очевидной хуйни вида "здесь лежит форма сведений о семейном положении пользователя", можно добавить следующие. Ебучие выпадающие списки. На мой взгляд, мы подошли к реализации ввода значения из справочника из рук вон плохо. Основная претензия: значения свойства, по факту, лежат в КЛЮЧАХ справочиника. `martialStatus: keyof typeof MarialStatus` - это жесть. Как сделать лакшери (имхо, разумеется) - на примере поля "семейное положение":

1. Создать тип

```
export enum MartialStatus {
  CIVIL_MARRIAGE = 'civil_marriage',
  UNMARRIED = 'unmarried',
  MARRIED = 'married',
  DIVORCED = 'divorced',
}
```

Это - тип значения поля `StatementModel.martialStatus`. Он используется в `value` и `onChange` select'a "семейное положение". Далее. В select'е мы определяем ещё одну коллекцию:

```
const Options = {
  [MartialStatus.CIVIL_MARRIAGE]: 'Гражданский брак',
  [MartialStatus.UNMARRIED]: 'Холост / не замужем',
  [MartialStatus.MARRIED]: 'Женат / замужем',
  [MartialStatus.DIVORCED]: 'В разводе',
};
```

и уже её юзать в хуке, что поставляется вместе с `Select`. По факту, тут мы объявили маппинг "значение из справочиника" - "то, что мы пишем в выпадаюшем списке". Таким образом, отображение отделено от данных, архитекторы ПО древности с радостью смотрят на нас из своих могил.

*application.contactPersons*

Нахуй `contactPersonPhoneA|B|C`. Заменяем его на массив с объектами `{ phone, type, name }`. Прям в модели `Statement`.

*application.income*

Сабж.

*application.agreements*

Чекбоксы с третьего шага уползают сюда. Сюда же уползает функционал по из загрузке с сервера.

*application.confirmation*

Подписание заявки будет жить тут.

*application.document*

Здесь будет жить Анкета-Заявление и функционал по получению её с сервера. Как, не видели никакой анкеты-заявления? Да вот же, серенькие слова в тесте под формой на третьем шаге заявки, такие же серенькие, как и остальной текст. Но вообще, при нажатии на эту неприметную (и заблокированную сейчас) кнопку заявка должна отправляться на сервер, и тот отдаст нам ссылку на документ, который, по сути, представляет собой печатную версию этой самой заявки. Пока бэк ещё не реализовал этот функционал, но обещают.

*application.steps*

Весь функционал по разбивке заявки по шагам, будет жить тут. Здесь же, кстати, будут жить и компоненты страниц `FirstStepPage`, `SecondStepPage` и `ThirdStepPage`.