Разработка платформы онлайн-курсов: роли, контент, прогресс и оплата

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

В этой статье разберём состав собственной EdTech-платформы на примере HarmonizeME. Мы не будем приписывать проекту универсальную «идеальную архитектуру» или выдуманные показатели. Основа материала — реально реализованные сценарии: готовые и персональные курсы, личный кабинет, платежи в двух валютах, сроки доступа, прогресс, бонусы и HarmoMarket.

Подробное описание проекта доступно в кейсе HarmonizeME.

Когда нужна собственная платформа

Сначала стоит проверить готовые решения. Stepik сочетает конструктор и площадку для публикации курсов, Skillspace предлагает инструменты создания и продажи обучения. Для типового курса это быстрее и дешевле кастомной разработки.

Собственная платформа становится рациональным вариантом, если:

• логика обучения является частью конкурентного преимущества;
• пользователь собирает персональную программу;
• один аккаунт объединяет обучение, покупки, бонусы и контент;
• нужны нестандартные сроки и правила доступа;
• коммерческий сценарий работает в нескольких валютах;
• готовые интеграции требуют постоянного ручного обхода;
• бизнесу нужен полный контроль над интерфейсом и данными;
• продукт планируется развивать как самостоятельный сервис.

Если отличие сводится к цветам и логотипу, разумнее настроить готовую LMS. Если приходится ломать её базовую модель, собственная разработка может оказаться предсказуемее.

С чего начать техническое задание

Не начинайте с перечня экранов. Сначала опишите состояния ключевых сущностей.

Пользователь

• гость;
• зарегистрирован, но не подтвердил контакт;
• активен;
• заблокирован;
• имеет один или несколько доступов;
• использует русский или английский интерфейс.

Заказ

• создан;
• ожидает оплаты;
• оплачен;
• отменён;
• возвращён;
• требует ручной проверки.

Доступ

• ещё не начался;
• активен;
• заканчивается;
• завершён;
• продлён;
• отозван.

Урок

• недоступен;
• доступен;
• начат;
• завершён;
• требует повторного действия.

Когда состояния согласованы, экраны и API проектируются вокруг переходов между ними. Это снижает количество противоречий: например, оплаченный заказ не должен существовать без выданного доступа.

Основные роли

Минимум нужно разделить три роли.

Ученик покупает программу, проходит уроки, видит прогресс и управляет своим профилем.

Автор или методист создаёт курсы, уроки, публикации и цифровые товары.

Администратор управляет пользователями, заказами, доступами и системными настройками.

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

Принцип наименьших привилегий особенно важен для платежей и персональных данных. Редактору контента не нужен доступ к заказам, а сотруднику поддержки — возможность менять глобальные настройки.

Как устроить модель контента

Простая иерархия выглядит так:

• курс;
• модуль;
• урок;
• контентный блок;
• файл или видео;
• задание;
• условие завершения.

Но продуктовые требования могут расширить модель:

• один урок используется в нескольких программах;
• курс продаётся целиком или собирается из отдельных видео;
• материалы существуют на нескольких языках;
• публикация обновляется без изменения уже купленной версии;
• доступ к уроку зависит от даты или предыдущего шага.

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

Если объединить их в одну таблицу «курсы», любое изменение цены или состава начнёт влиять на историю старых заказов.

Почему каталог и конструктор — разные сценарии

Каталог отвечает на вопрос «какую готовую программу выбрать». Конструктор — «какие элементы включить в собственный путь».

Для каталога важны:

• описание результата и аудитории;
• состав программы;
• формат;
• срок доступа;
• цена;
• язык;
• статус доступности.

Для конструктора:

• фильтры и темы;
• описание отдельного материала;
• выбранный набор;
• итоговая стоимость;
• ограничения совместимости;
• порядок прохождения;
• сохранение незавершённого выбора.

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

Личный кабинет и доступ

Личный кабинет — не список купленных карточек. Он должен объяснять текущее состояние обучения.

Пользователю нужны:

• активные и завершённые программы;
• срок доступа;
• последний открытый материал;
• прогресс;
• следующий шаг;
• история заказов;
• возможность продления, если она предусмотрена;
• понятная причина недоступности.

Проверка доступа выполняется на сервере при каждом защищённом запросе. Скрытая кнопка в интерфейсе не защищает видео или файл от прямого обращения.

Правило доступа может учитывать:

• оплаченный заказ;
• дату начала и окончания;
• роль;
• язык;
• конкретный продукт;
• ручную выдачу;
• продление;
• возврат платежа.

Чем больше условий, тем важнее единый сервис авторизации доступа, а не повторение логики в разных контроллерах.

Как считать прогресс

Процент курса кажется простой величиной, но сначала нужно определить знаменатель.

Варианты:

• количество открытых уроков;
• количество обязательных уроков;
• длительность видео;
• выполненные задания;
• завершённые модули.

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

Практичная модель хранит события или отдельные состояния по урокам:

• начат;
• достигнута контрольная точка;
• завершён;
• отмечен вручную;
• сброшен администратором.

Общий прогресс курса вычисляется из этих данных. Историю изменения лучше не терять: она помогает службе поддержки разбирать спорные случаи.

Платежи и выдача доступа

Критическая ошибка — выдавать доступ только на основании возврата пользователя на страницу «Оплата прошла». Пользователь может закрыть вкладку, сеть может оборваться, а ссылку можно открыть повторно.

Надёжный сценарий:

1. Сервер создаёт заказ со своей суммой и составом.
2. Платёжный провайдер получает идентификатор заказа.
3. После оплаты сервер принимает подписанное уведомление.
4. Проверяет провайдера, сумму, валюту и идемпотентность.
5. Меняет состояние заказа.
6. Выдаёт доступ один раз.
7. Записывает операцию в журнал.
8. Отправляет уведомление пользователю.

Повторное уведомление не должно повторно начислять бонусы или создавать второй доступ.

В HarmonizeME коммерческий сценарий поддерживает цены в рублях и долларах. Для международной платформы валюта фиксируется в заказе: её нельзя заново вычислять по текущему интерфейсу после оплаты.

Видео и файлы

Видео обычно тяжелее всего остального контента и требует отдельного решения по хранению и доставке.

Нужно определить:

• куда загружается оригинал;
• нужны ли несколько качеств;
• как ограничивается прямой доступ;
• поддерживается ли продолжение просмотра;
• как обрабатываются субтитры;
• что происходит при замене файла;
• сколько хранится старая версия;
• какие данные отправляются в аналитику.

В архитектуре HarmonizeME файлы размещаются в S3-совместимом хранилище. Приложение хранит метаданные и права, а не передаёт тяжёлый файл через основной сервер при каждом просмотре.

Бонусы как финансовоподобный контур

Бонусы не являются просто числом в профиле. Если пользователь может получить и потратить их, нужна история операций.

Для каждой записи полезно хранить:

• тип операции;
• сумму;
• основание;
• связанный урок или заказ;
• дату;
• инициатора;
• результат;
• ключ защиты от повторного начисления.

Баланс вычисляется из подтверждённых операций или обновляется транзакционно вместе с журналом. Нельзя сначала списать бонусы, а потом попытаться создать заказ без возможности отката.

В HarmonizeME бонусы начисляются за обучение и используются в HarmoMarket для курсов, файлов и специальных предложений. Эта механика связывает прогресс с возвращением в продукт, но требует тех же проверок повторов и прав, что и платёжный сценарий.

Административная панель

Админка должна отражать реальные процессы команды, а не просто давать CRUD для таблиц базы.

Для контента нужны:

• черновики;
• предпросмотр;
• публикация и снятие с публикации;
• порядок модулей и уроков;
• поиск;
• языковые версии;
• предупреждение о связанных данных.

Для пользователей и заказов:

• поиск по безопасным идентификаторам;
• история доступов;
• журнал платежных событий;
• ручное продление с указанием причины;
• запрет опасных действий без подтверждения;
• аудит изменений.

Особенно полезно показывать не только текущее значение, но и кто, когда и почему его изменил.

Архитектура HarmonizeME

Подтверждённый стек проекта:

• Next.js и React на клиенте;
• TypeScript;
• AdonisJS для серверного API;
• PostgreSQL для пользователей, курсов, заказов, доступов, прогресса и бонусных операций;
• CloudPayments для платёжного сценария;
• S3-совместимое хранилище для файлов;
• SMTP для уведомлений;
• Яндекс Метрика для продуктовой аналитики.

Это не означает, что такой стек нужен каждой школе. Важнее разделение ответственности:

• клиент показывает состояние и отправляет команды;
• API проверяет права и бизнес-правила;
• база сохраняет целостное состояние;
• фоновые задачи обрабатывают сроки и уведомления;
• платёжные события проходят независимую проверку;
• файлы хранятся отдельно от прикладного сервера.

События для аналитики

Аналитику лучше проектировать вместе с пользовательским маршрутом.

Базовые события:

• просмотр страницы курса;
• начало оформления;
• создание заказа;
• подтверждение оплаты;
• первый запуск урока;
• завершение урока;
• завершение курса;
• начисление и трата бонусов;
• продление доступа;
• ошибка воспроизведения;
• обращение в поддержку.

Не собирайте данные «на всякий случай». Для каждого события должен быть вопрос, на который команда собирается отвечать. Персональные данные и чувствительные сведения требуют отдельной правовой и информационной проверки.

Безопасность и эксплуатация

До запуска проверьте:

• серверную авторизацию каждого защищённого запроса;
• хранение паролей и восстановление доступа;
• ограничение попыток входа;
• проверку платёжных уведомлений;
• защиту загрузки файлов;
• резервное копирование;
• журнал действий администратора;
• мониторинг ошибок;
• процедуру отзыва доступа;
• политику обработки персональных данных.

Для психологических и образовательных продуктов также важно не смешивать обучение с медицинской услугой в формулировках интерфейса. Платформа должна точно описывать свою роль и не обещать недоказанный результат.

Как разбить разработку на этапы

Этап 1. Аналитика

Описать роли, контент, состояния заказов, доступы, прогресс, валюты и административные процессы.

Этап 2. Базовое обучение

Запустить каталог, регистрацию, оплату, личный кабинет, материалы и сохранение прогресса.

Этап 3. Управление продуктом

Добавить полноценную админку, публикации, поиск, уведомления и аналитику.

Этап 4. Уникальная механика

Развивать конструктор персональной программы, бонусы, HarmoMarket и другие отличия от готовой LMS.

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

Чек-лист перед стартом

• Понятно, почему готовая LMS не подходит.
• Описаны роли и разрешения.
• Контент отделён от товара и доступа.
• Зафиксированы состояния заказа.
• Определён критерий завершения каждого типа урока.
• Платёжное уведомление обрабатывается идемпотентно.
• Доступ проверяется на сервере.
• Бонусы имеют журнал операций.
• Автор может управлять контентом без разработчика.
• Продуманы языки, валюты и сроки доступа.
• Определены аналитические события.
• Есть резервное копирование и аудит админ-действий.

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

Если готовая система не покрывает ваш сценарий, начните с аудита и описания бизнес-процессов, а затем оцените разработку собственного веб-сервиса.

---

Теги: Платформа онлайн-курсов, EdTech, LMS, Личный кабинет, Платежи Дата обновления: 25 сентября 2026