Project Builder Platform: инженерные проекты, аукционы и документооборот

Project Builder Platform - продуктовая система для управления инженерными проектами. Внутри одного процесса встречались заказчики, модераторы, главные инженеры, исполнители и администраторы. Пользователь мог пройти путь от создания проекта до торгов, обсуждений, загрузки документов, согласований и закрытия работ.

Главная сложность была не в том, чтобы сделать набор CRUD-экранов. Сложность была в правилах: кто и когда видит действие, какие статусы можно менять вручную, какие процессы должны завершаться автоматически, какие уведомления нельзя потерять, как хранить версии документов и как не смешать бизнес-логику с GraphQL-resolver'ами.

Моя роль

Я занимался backend-архитектурой и ключевыми бизнес-модулями. В течение части проекта также вел fullstack-разработку и довел продукт до MVP-состояния: backend, frontend-сценарии, инфраструктура и деплойный контур.

В зоне ответственности были:

• архитектура backend на Clean Architecture и CQRS;
• GraphQL API на NestJS/Fastify;
• доменная модель проектов, ролей, аукционов, файлов и документов;
• аукционная система с раундами, статусами, автозавершением и real-time обновлениями;
• чаты, уведомления и фоновые задачи через Redis, BullMQ и WebSocket;
• документооборот: версии файлов, цепочки подписания, загрузка в S3 и асинхронная PDF-конвертация;
• Docker-инфраструктура, CI/CD и процесс доставки на окружения.

Архитектурный подход

Я разделял транспортный слой и бизнес-сценарии. Resolver принимал запрос и валидировал входные данные, а дальше управление уходило в command/query handler. Правила статусов, проверки доступов, побочные эффекты и работа с хранилищем жили в доменных сервисах и репозиториях.

Такой подход был важен из-за количества сценариев. Например, аукцион не сводился к таблице ставок: у него были раунды, ограничения по времени, состояние участников, события для интерфейса и фоновые задачи. Документы тоже были не просто файлами: у них появлялись версии, цепочки подписания, история и задачи на конвертацию.

Что было нетривиальным

Самым чувствительным местом были переходы состояний. Если разложить их по контроллерам, проект быстро становится хрупким: одно новое условие ломает соседние сценарии. Поэтому workflow выносился в отдельные места, где можно было явно видеть допустимые переходы и права.

Вторая сложность - асинхронность. Уведомления, автозавершение торгов и обработка документов не должны были блокировать пользовательские действия. Для этого использовались очереди и Redis, а realtime-события отдавались отдельно от основного запроса.

Результат

Получился MVP сложной платформы, где в одном продукте работали роли, торги, документы, уведомления, чаты и управление проектами. Для меня это был сильный кейс именно про инженерное мышление: не просто написать API, а удержать доменную модель так, чтобы продукт можно было развивать дальше без переписывания ядра.