$ case open banking-onboarding
Как onboarding для пяти приложений стал общей платформой
Архитектурный разбор React/TypeScript-библиотеки: как отделить продуктовые различия от общих flow, сложных форм и workflow.
- 5
- приложений на общей библиотеке
- 6–10
- шагов в product flow
- 273
- конфигурируемых поля
- ≈3 мес.
- до первого рабочего flow
01 / Контекст
Один onboarding, но разные продукты и роли
Банковская платформа запускалась с нуля командой из трёх frontend-разработчиков. Задача была не в сборке одной многошаговой формы, а в системе, которая масштабируется на несколько продуктов.
Моя роль
Senior Frontend Developer: запуск платформы, общие библиотеки, workflow и интеграция в shell.
Два контура
Клиентский onboarding и staff/compliance-сценарии для сотрудников банка.
Сложность домена
Юрлица, UBO, подписанты, вложенные сущности, документы/OCR, OTP и асинхронные проверки.
02 / Архитектура
Вариативность в конфиге, сложность в общем core
Переключай слои: интерактив показывает, где живут продуктовые различия, общая логика, workflow и границы доставки.
Различия продуктов описываются данными
Продукты меняют flow без копирования общих страниц.
- Шаги и секции
- Поля, тексты и словари
- Правила работы с документами
03 / Решения
Четыре границы, которые удерживают систему
Конфигурация вместо fork’ов
Шаги, поля, секции, тексты и правила задаются продуктом.
Строже схема конфига, зато меньше расхождений.Две общие библиотеки
Клиентский onboarding и staff/compliance переиспользуют workflow, проверки и документы.
Нужны явные API и правила обратной совместимости.Saga для orchestration
Последовательные и параллельные проверки не растворяются в UI-коде.
Больше явной orchestration-логики, зато проще контролировать статусы.Маршруты как контракт remote
Каждое onboarding-приложение отдаёт маршруты в общий shell.
Версии shared-зависимостей и границы remote нужно контролировать.04 / Результат
Общие страницы переиспользуются без расхождения продуктов
Ценность архитектуры не в самом факте выноса кода в библиотеку, а в управляемой вариативности: общее меняется один раз, а различия остаются в конфигах продуктов.
- 5
- приложений на shared onboarding
- 4
- приложения без отдельных fork’ов
- 26
- статусов staff workflow
- 9
- ролей внутренних пользователей
Масштаб
От 6–10 шагов до 273 полей и 65 секций.
Переиспользование
Общие решения для client и staff-контуров.
Доставка
Remotes отдают маршруты и подключаются в shell.
$ next case
Посмотреть performance-кейс SFERA
Там — расследование утечек памяти в real-time React-интерфейсе.