Основы системного дизайна на примере записи к мастеру

Разбор лекции Ивана Балашова от 15 октября 2026 года из библиотеки стримов Guide DAO.

Иван Балашов работает Head of Development в SOFTSWISS. В разработке он больше десяти лет, в том числе работал в Ozon и DDL. Последние полтора года Иван активно пользуется LLM, а последний год почти не пишет код вручную. Вайбкодеру, считает Иван, полезно понимать, что он делает и как это должно работать. Поэтому Иван начал цикл лекций о системном дизайне. Первая лекция начинается с самой базы. Иван проектирует сервис записи к барберу сначала на схеме, потом вместе с Claude, и показывает, где план агента приходится править.

Опытный разработчик, по словам Ивана, любую систему сначала прорабатывает на бумаге. У самого Ивана до сих пор под рукой тетрадка с ручкой. Пока рисуешь схему, задаёшь себе вопросы, сам на них отвечаешь и находишь корнер-кейсы, то есть крайние случаи, в которых система поведёт себя не так, как ты ждёшь. Это экономит много времени и сил, а программировать для этого уметь не нужно. Достаточно понимать, как всё должно работать.

Пример для лекции Иван попросил у Claude, и тот предложил запись к мастеру. Ивану идея понравилась тем, что она понятная, взята из жизни и легко раскладывается на компоненты. Мастером стал барбер, а схему Иван рисовал в Excalidraw.

Сначала он выписал, кто пользуется системой и чего каждый от неё ждёт. Клиент хочет видеть услуги мастера и свободные временные слоты, записываться, смотреть историю походов, отменять и переносить запись. Мастер хочет видеть занятые слоты и данные клиента, то есть ФИО, email и телефон, управлять услугами и записями и получать статистику.

Под требованиями Иван набросал блоки, из которых будет состоять система. Для клиента и мастера хватит одной сущности «Пользователь», две разные, по опыту Ивана, не нужны. Ещё два блока описывают услуги и расписание.

Стрелками Иван показал, кому что принадлежит. Услуги принадлежат мастеру: он их создаёт, редактирует и удаляет, а клиент только видит и выбирает. Привязать услуги Иван решил к мастеру, а не к расписанию, потому что в свободный слот мастер может оказать любую из, скажем, десяти своих услуг. Расписание тоже принадлежит мастеру. Последней появилась сущность «Заказ», она принадлежит и мастеру, и клиенту.

Схему Иван проверил сценарием. Клиент выбирает услугу, с ней выбирает место в расписании и формирует заказ, а мастер этот заказ выполняет. Для предварительной версии этого хватает.

Затем Иван открыл пустую папку проекта, запустил Claude на модели Opus и написал первый промпт. Нужен Telegram-бот для барбера, язык программирования неважен, можно Python или Go. К промпту Иван приложил скриншот схемы и попросил, прежде чем что-то делать, спроектировать примерную архитектуру приложения.

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

Потом пошли вопросы. Сколько мастеров будет в системе? Один мастер, один бот. Это реальный бот для живых клиентов или пет-проект для портфолио? Реальный. Запись сразу считается подтверждённой или её подтверждает мастер? Подтверждает мастер. Запрещать ли отмену позже чем за три часа до визита? Иван решил обойтись без ограничений: «Зачем нам мучить человека?» Как мастер узнает о новых заявках, а клиент о подтверждении? Сообщением при каждом событии.

Вопросы хорошие, признал Иван, и по-хорошему о них стоило подумать самому. Но схему он набросал на скорую руку, чтобы сэкономить время, а агент учёл детали, которые на верхнем уровне легко пропустить.

Стек Claude предложил на выбор. Рекомендовал он Python с фреймворком aiogram 3 и интерфейсом на inline-кнопках прямо в чате. Минус в том, что недельный шаблон расписания кнопками редактировать неудобно. Мини-приложение Telegram на TypeScript и React получилось бы красивее, с нормальным календарём и удобной админкой, но это по сути два приложения и примерно вдвое больше работы. Иван выбрал Python. Для начала это хороший вариант, а при масштабировании, пошутил он, Python тоже можно натянуть на любой нужный глобус.

Claude разделил приложение на три слоя. Так, по словам Ивана, устроены почти все приложения.

Слой представления, как Claude перевёл английское Presentation Layer, Иван называет слоем отображения. Он отвечает за интерфейс: здесь это Telegram-бот, у десктопной программы был бы, например, Qt. Слой бизнес-логики описывает поведение приложения: какие события как обрабатывать и на какие отвечать. Слой данных, или Repository Layer, прячет от бизнес-логики, где лежат данные. Под капотом может стоять PostgreSQL, MySQL или MongoDB, а код от этого выбора зависеть не должен.

Как слои выглядят в коде, Иван показал на своём проекте. Слой API там только принимает вызов, смотрит, кто его делает, проверяет данные и передаёт работу дальше. Бизнес-логика лежит в папке use cases, в Python-проекте она называлась бы domain. Сценарий смены пароля проверяет права пользователя, текущий пароль и историю старых паролей, а потом сохраняет новый. Заодно Иван нашёл у себя ошибку. В бизнес-логику протёк кусок работы с базой, хотя запросам к базе место в слое данных, в репозиториях.

Иван советует попросить у Claude такую схему слоёв или описание в README. Тогда понятно, что за что отвечает, о чём вы разговариваете с «этой железякой» и что она у вас спрашивает.

Следом Claude предложил модель данных. В таблице клиентов лежат Telegram ID, имя, телефон и дата создания. В таблице услуг есть название, длительность в минутах, цена и флажок активности. Флажок нужен для временных услуг, ведь хэллоуинский маникюр не в Хэллоуин недоступен. Заказы со схемы Ивана попали в таблицу bookings.

Расписание же Claude разложил на три таблицы: рабочие часы по дням недели, выходные и дополнительные часы. Иван написал агенту: «Ты разбил расписание на три таблицы, кажется, можно сделать лаконичнее». Связей, то есть внешних ключей, между этими таблицами нет, объяснил Иван, и данные в них могут разбежаться. Claude согласился. Дополнительные часы и выходные по сути одно и то же, интервал со знаком плюс или минус, а недельный шаблон отличается от них только днями, к которым интервал применяется. Всё уместилось в одну таблицу правил, где в каждой строке указан день недели или диапазон дат, а ещё время начала и конца.

Заметить такое с первого взгляда помогает насмотренность, говорит Иван, и её придётся нарабатывать.

Дальше Claude описал жизненный цикл записи. Новая заявка получает статус pending, мастер переводит её в confirmed или rejected, отменённая запись уходит в canceled. Подтверждённая запись, время которой прошло, считается состоявшейся. Отдельного статуса для переноса нет. Запись меняется на месте, снова становится pending и ждёт подтверждения мастера. Клиент работает только со своими будущими записями, мастер с любыми, и на каждое событие уходит своё сообщение.

Свободные слоты считает алгоритм. Он склеивает интервалы из правил расписания в рабочее время, вычитает занятое и нарезает остаток на слоты с учётом длительности услуги. Ещё Claude предусмотрел защиту от гонок: при создании или изменении записи слоты пересчитываются заново, чтобы два клиента не заняли одно окно.

Провести через такое проектирование за ручку и подсказать косяки, по словам Ивана, может Claude и любой современный агент для разработки вроде Codex. Но схему он всё равно советует рисовать самому.

Напоследок Claude показал структуру проекта, где каждый слой стал отдельной папкой, а деплой Иван попросил пока оставить вне скоупа. Доделать приложение Иван оставил Claude на выходные.

Такой базовый дизайн Иван называет шагом номер минус один, самым важным. Нужно сесть и понять, какие в приложении есть сущности и как они относятся друг к другу.

Руку Иван набивал ещё в университете, где учился на инженера по фундаментальной информатике и информационным технологиям. Однажды он проектировал программу для лифта. Едет вверх, значит, останавливается везде, где нажали «вверх». Когда лифтом никто не пользуется, ему лучше ждать на первом этаже, потому что со всех этажей люди едут на первый, а приходя, поднимаются с него. Такие задачи приучают спрашивать себя, кто есть кто, кто за что отвечает, кто какие данные видит и что может добавить, поменять или удалить.

Агенты помогают и здесь, задают наводящие вопросы и требуют ответа. Claude сам проговорил корнер-кейсы вроде поздней отмены. Но сложных корнер-кейсов агенты, по опыту Ивана, всё равно пропускают очень много, а реальные системы бывают куда сложнее записи на стрижку. Дальше в цикле Иван собирается развивать этот сервис, а потом представить, что мастеров и клиентов стало по миллиону.

Прежде чем открывать агента, нарисуйте схему. Выпишите роли и то, чего каждая ждёт от системы, потом сущности и стрелки, кому что принадлежит, и проведите по схеме главный сценарий пользователя. Хватит тетрадки или Excalidraw.

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

Попросите агента описать слои в схеме или в README. Проверьте, что бизнес-логика не знает, какая база стоит под капотом.

Читайте модель данных критически. Если одно понятие разложено по нескольким несвязанным таблицам, спросите, нельзя ли проще. Отдельно проверьте статусы главной сущности: кто и куда может её перевести и что происходит при переносе.

Тренируйтесь на бытовых системах вроде лифта и не рассчитывайте, что агент найдёт все корнер-кейсы за вас.