AKHN: архитектурный переход маркетплейс-платформы с REST-монолита на GraphQL/DDD

AKHN — маркетплейс-платформа, соединяющая заказчиков с инженерными командами-подрядчиками. Система состоит из трёх приложений: публичный сайт (каталог команд, заявки, создание заказа с лендинга), основное приложение — личный кабинет для обеих сторон (заказы, команды, документы, финансы, чат), и backend.

Веду архитектурный переход бэкенда и синхронный рефакторинг фронтенда — не переписывание с нуля, а управляемый переход без остановки продукта.

Бизнес-домен

Платформа покрывает: аутентификацию, пользователей двух типов (частные лица/бизнес), команды с ролевой моделью и системой приглашений, полный жизненный цикл заказа (от черновика до спора и завершения), документооборот с генерацией договоров, финансы и платежи (несколько провайдеров), встроенный мессенджер с чатами в реальном времени, уведомления, RBAC-доступ и админ-панель.

Что было

Backend — NestJS-монолит с REST API поверх MySQL, часть модулей уже частично использовала CQRS-паттерн, но без единой архитектурной дисциплины по всему проекту.

Куда веду

Новый backend строю по DDD-слоям (domain/application/infrastructure/ presentation) с CQRS по каждому бизнес-модулю, на GraphQL вместо REST и PostgreSQL вместо MySQL. Права доступа — CASL с уровневой моделью: тип пользователя → глобальные права → контекстная роль внутри конкретной команды.

Миграция фронтенда

Фронтенд подстраивается под новый бэкенд, а не наоборот:

• Redux заменяется на Apollo Client — реактивный GraphQL-кэш вместо глобального store.
• REST-запросы переводятся на GraphQL-операции, за одним осознанным исключением (внешняя OAuth-интеграция, которую не стал подгонять под GraphQL ради консистентности).
• Архитектура фронтенда переезжает на Feature-Sliced Design, при этом весь UI-код (дизайн-система, компоненты) переносится без изменений — рефакторится структура, не внешний вид.
• Отдельная задача — рассинхронизация терминологии между старым фронтендом и новым бэкендом (переименованные роли, статусы заказов): все соответствия свожу в единую таблицу маппинга, чтобы старые значения не расползались по кодовой базе.

Миграция идёт поэтапно, от простого и низкорискового (инфраструктура, авторизация) к сложному (мессенджер — последним, отдельным этапом).

Верификация через аудит

Помимо тестов, использую систематическую сверку фронтенд-кода с живой GraphQL-схемой бэкенда: построчно проверяю, что каждая операция, каждое сравнение с значением статуса/роли и каждая проверка прав соответствуют тому, что реально отдаёт сервер — а не тому, что написано в фронтенд-коде "по памяти". Так нашлись реальные баги ещё до продакшена: опечатка в одной букве в фильтре статуса заказа, из-за которой фильтр просто не находил бы ничего, обработчики без обработки сетевых ошибок, и захардкоженная пагинация, из-за которой часть пользователей была бы недоступна в админ-панели.

Результат

Весь проект — все три приложения и сама архитектурная миграция — веду самостоятельно, от проектирования архитектуры и выбора стека до построчного аудита фронтенда против реальной схемы бэкенда.