Студия запускает несколько продуктов подряд, и каждый раз бэкенд пишется заново: авторизация, профили, платежи, уведомления, хранилище. Новый проект — снова те же три месяца на то, что уже делали.
← Все проекты
Сервисы и приложения · Архитектура и ТЗ · в разработке
Wellness-приложение и фундамент для следующих продуктов
Приложение с трекером практик, AI-дневником, медитациями и подпиской спроектировано так, что следующий продукт студии не начинается с нуля. Авторизация, профили, платежи и уведомления переходят в него готовыми.
15готовых модулей, от авторизации до аналитики
0карточных данных на серверах приложения
1настройка вместо кода при запуске нового продукта
Задача
Что сделали
Следующий продукт не с нуля
Трекер практик, AI-дневник, медитации, подписка описаны поверх модульного SDK: код описывает интерфейс, данные описывают поведение.
Понятно, что брать готовым, а что писать
«Уже есть в SDK / расширяем провайдером / специфика проекта» — и для каждой сущности единственный владелец данных.
Платежи подключаются один раз на все продукты
Не интеграция в проект, а провайдер, который следующий продукт просто включит.
Исполнителя можно выбрать любого
API-контракты и DDL оставлены исполнителю: не навязывать физическую схему до выбора команды.
Исполнитель видит, почему решено именно так
Семь замечаний архитектора закрыты, каждое с ответом лежит в разделе «Решения v5–v9». Исполнитель видит не только итог, но и почему он такой.
Почему этому можно верить
- Кому принадлежит транзакция
- Финансовому учёту, потому что именно он решает, получены деньги или нет. Платёжный сервис живёт без базы: получил команду, сходил к провайдеру, вернул результат.
- Карточные данные
- До нашего сервера не доходят. Клиент формирует криптограмму, бэкенд передаёт её провайдеру. PCI DSS закрывается архитектурой, а не аудитом.
- Новый провайдер
- Адаптер плюс блок в config.yml, ядро не трогается. Статусы провайдера маппятся в статусы SDK, вебхук у каждого свой, с проверкой подписи.
- Схема платежа
- Одностадийная. Подписке хватает charge, двухстадийный auth+confirm только усложнил бы. Возврат средств архитектор вынес за MVP, и это записано как решение, а не как пробел.
Как устроено
- Клиент
- React Native. SDK провайдера на стороне приложения делает криптограмму и 3-D Secure.
- Сервисы
- Пятнадцать: аутентификация, профили, организации, хранилище, уведомления, каталог, финансовый учёт, платежи, задачи, чат, AI, распознавание, CMS, аналитика, персонализация. У каждого своя схема в PostgreSQL. У платежей базы нет.
- События
- Каталог событий; платёж стартует от события создания счёта в финансовом учёте.
- Конфигурация
- config.yml и seed data на проект. Хранилище, уведомления, платежи, AI и распознавание подключаются как провайдеры через конфиг.
- Документация
- Три уровня: архитектура, модели данных с бизнес-правилами, флоу процессов. База знаний из связанных документов, OpenAPI генерируется из неё.
Похожая задача?
Опишите её — пришлём состав работ и смету за 24 часа.