Представьте, что вам пришла идея создать образовательную платформу.
На первый взгляд всё выглядит просто. Человек заходит на сайт или в приложение, выбирает курс, оформляет подписку, открывает первый урок — видео, текст, задание. Отмечает урок как пройденный, двигается дальше. В конце курса получает сертификат.
Для студента это несколько привычных действий. Но за этой простой историей скрывается целая система.
Как платформа понимает, что у этого студента есть активная подписка? Где хранятся курсы, уроки, задания, прогресс, сертификаты? Что происходит, если платёж за продление подписки не прошёл — студент теряет доступ прямо посреди курса? Кто может публиковать курсы, а кто только смотреть? Как автор загружает видео весом несколько гигабайт? Как платформа отправляет студенту письмо о завершении курса? Как встроить в урок интерактивную симуляцию — не просто видео, а среду, где можно что-то попробовать руками? Как приложение работает на телефоне без интернета? Что произойдёт, если тысячи студентов одновременно откроют новый популярный курс?
И самый важный вопрос: как собрать всё это в одну понятную и устойчивую систему, а не в хаотичный набор экранов, кнопок и таблиц?
Именно с этого начинается системное проектирование.
Курс не про код, а про устройство продукта
Многие думают, что путь в IT обязательно начинается с языка программирования. Нужно выбрать Python, JavaScript, C# или Java, выучить переменные, циклы, функции, классы, а потом постепенно всё станет понятно.
Такой путь действительно существует. Программирование важно. Но есть проблема: знание синтаксиса само по себе не объясняет, как устроен реальный цифровой продукт.
Можно уметь писать небольшие программы и всё равно теряться перед вопросами:
- где должна храниться информация;
- кто имеет доступ к разным действиям;
- как части системы обмениваются данными;
- что происходит на сервере;
- зачем нужна база данных;
- чем фронтенд отличается от бэкенда;
- как приложение публикуется в интернете;
- как система выдерживает рост нагрузки;
- где появляются ошибки и как их отслеживают.
Этот курс идёт другим путём. Мы не начинаем с кода. Мы начинаем с понимания системы.
Наша задача — научиться смотреть на цифровой продукт как проектировщик. Не как человек, который сразу спрашивает «на каком языке это написать?», а как человек, который сначала понимает:
- кто участвует в системе;
- какие действия они выполняют;
- какие данные при этом появляются;
- какие правила нельзя нарушать;
- какие части нужны внутри продукта;
- как эти части связаны друг с другом;
- какие решения можно выбрать на каждом уровне.
Код — это способ реализовать решение. Но перед кодом всегда должна быть сама логика системы.
Наш сквозной пример — Stratum
На протяжении курса мы будем постепенно собирать Stratum — образовательную платформу с подпиской.
Сначала она будет выглядеть как обычная идея: «хочу сервис, где люди проходят онлайн-курсы». Потом мы начнём раскладывать её на части.
У нас появятся участники:
- студент, который выбирает курс, оформляет подписку и учится;
- автор, который создаёт курсы, загружает материалы и публикует контент;
- администратор платформы, который модерирует контент и управляет тарифами;
- платёжный сервис, который обрабатывает подписки и продления;
- сервис уведомлений, который отправляет письма и push-сообщения;
- облачное хранилище, которое держит видео, изображения и файлы.
Потом появятся сценарии. Студент выбирает курс. Студент оформляет подписку. Студент проходит урок с интерактивной симуляцией. Студент получает сертификат. Автор создаёт новый курс в десктопном редакторе. Автор загружает видео. Платформа отправляет письмо о завершении курса. Платёжный сервис сообщает, что очередное списание не прошло.
После этого мы увидим правила. Нельзя смотреть урок без активной подписки. Нельзя опубликовать курс без прохождения модерации. Нельзя редактировать чужой курс. Нельзя считать подписку оплаченной до подтверждения от платёжного сервиса. Нельзя показывать прогресс одного студента другому.
Так из простой идеи постепенно рождается логика продукта.
Система — это не один экран и не одна база
Когда студент видит Stratum, он обычно видит только внешний слой: каталог курсов, страницу урока, видеоплеер, задание, кнопку «Отметить как пройденное».
Но за интерфейсом есть другие слои.
Есть серверная часть. Она принимает действия пользователя, проверяет правила, проверяет статус подписки, обновляет прогресс, связывается с платёжным сервисом и возвращает результат.
Есть база данных. В ней хранятся пользователи, курсы, уроки, задания, прогресс, подписки, платежи и другие важные сведения.
Есть API. Это способ, с помощью которого разные части системы разговаривают друг с другом. Мобильное приложение спрашивает сервер: «есть ли у этого студента активная подписка?». Десктопный редактор автора отправляет новый урок на публикацию. Unity-симуляция внутри курса сообщает серверу, что студент успешно завершил задание.
Есть несколько клиентов одной системы. Студент учится через браузер или мобильное приложение. Автор создаёт контент в десктопном редакторе. Некоторые уроки содержат интерактивные симуляции, которые работают на Unity прямо внутри страницы курса. Все они обращаются к одному бэкенду.
Есть внешние сервисы. Платежи, письма, push-уведомления, хранилище видео, аналитика, транскрибация — всё это часто подключается через готовые решения.
Есть инфраструктура. Где работает сервер? Как хранятся видеофайлы размером в гигабайты? Как обновлять платформу без простоя? Как выдержать пиковую нагрузку, когда выходит популярный курс?
Современный IT-продукт — это не одна технология. Это набор связанных решений, каждое из которых отвечает за свою часть работы.
Кому подойдёт этот курс
Этот курс подойдёт людям без технического бэкграунда, которые хотят разобраться, как устроены современные IT-системы, но не хотят начинать с синтаксиса языков программирования.
Он также подойдёт тем, у кого уже есть опыт в IT или рядом с IT, но этот опыт пока охватывает только отдельную часть продукта. Например, человек может понимать дизайн интерфейсов, аналитику, маркетинг, тестирование, менеджмент, поддержку, контент, продажи или даже основы программирования, но при этом не видеть систему целиком.
В реальной разработке такое встречается постоянно. Один специалист хорошо понимает пользовательский интерфейс, другой работает с требованиями, третий пишет отдельные части кода, четвёртый занимается продвижением продукта. Но когда речь заходит о том, как всё связано между собой, — где хранятся данные, как работает сервер, кто имеет доступ к действиям, как устроена авторизация, что происходит при оплате и почему система может не выдержать нагрузку, — общей картины может не хватать.
Именно эту общую картину мы и будем собирать.
Мы не будем превращать каждый урок в разбор кода. Но мы будем разбирать технические идеи на понятном уровне.
Вам не нужно писать SQL-запросы, чтобы понять, что в Stratum есть таблица студентов, таблица курсов, таблица подписок и таблица прогресса. Важно увидеть, что прогресс связан со студентом, уроком и датой прохождения.
Вам не нужно программировать API, чтобы понять, что мобильное приложение должно уметь попросить сервер проверить подписку, открыть урок, отметить задание или получить сертификат.
Вам не нужно настраивать Docker руками, чтобы понять, зачем приложения упаковывают в контейнеры и почему это помогает запускать систему предсказуемо.
Цель курса — дать вам карту. Когда у человека есть карта, он уже не смотрит на IT-систему как на магию. Он понимает, какие там есть части, зачем они нужны и какие вопросы нужно задавать.
Как мыслит проектировщик системы
Проектировщик не начинает с кнопок и не заканчивает красивым экраном.
Он задаёт вопросы.
Кто будет пользоваться системой? Что каждый участник хочет сделать? Какие данные появляются в процессе? Какие действия должны быть разрешены, а какие запрещены? Что может пойти не так? Какие части системы должны между собой договориться? Что нужно сохранить навсегда, а что можно посчитать заново? Где система должна быть быстрой? Где она должна быть особенно надёжной?
Возьмём простое действие: студент завершил курс.
На уровне интерфейса это кнопка «Получить сертификат».
На уровне системы это цепочка событий:
- Пользователь нажимает кнопку.
- Система проверяет, пройдены ли все уроки и задания.
- Система проверяет, активна ли подписка на момент завершения.
- Система генерирует сертификат с уникальным идентификатором.
- Сертификат сохраняется в базе и привязывается к студенту и курсу.
- Студент получает письмо со ссылкой на сертификат.
- Сертификат доступен по публичной ссылке для подтверждения.
Одна кнопка превращается в несколько действий, правил, данных и взаимодействий. Именно так проектировщик смотрит на продукт: он видит не только экран, но и всё, что должно произойти за ним.
Что вы будете понимать после курса
К концу курса вы сможете взять идею цифрового продукта и разложить её на понятные части.
Вы будете понимать, где проходят границы системы, кто с ней взаимодействует, какие сценарии нужно описать, какие данные возникают, как они связаны, зачем нужен сервер, какую роль играет база данных, что такое API, как устроена авторизация, где появляются ограничения безопасности и почему инфраструктура важна не меньше интерфейса.
Вы также увидите, как система развивается, когда становится больше пользователей: зачем нужны кэширование, очереди, логирование, мониторинг, масштабирование и иногда микросервисы.
Главный результат — вы начнёте мыслить не отдельными функциями, а системой.
Это не заменяет программирование и не отменяет работу разработчиков. Но это даёт фундамент, без которого сложно понимать реальные продукты. Когда человек видит систему целиком, он увереннее общается с командой, лучше формулирует требования, быстрее замечает слабые места и осознаннее принимает решения.
В следующем уроке мы начнём с самого первого шага: определим, что именно является системой Stratum, где проходят её границы и что в неё входит, а что остаётся снаружи.