Проектируем архитектуру Битрикс до первой строки кода

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

Главная проблема: требования живут в головах, а не в документах

Самый частый источник провалов на сложных проектах — расхождение в понимании задачи. Заказчик держит в голове одну картину, аналитик слышит другую, разработчик додумывает третью. Пока проект маленький, это сходит с рук, но на системе с десятком ролей, персональными ценами и интеграциями каждое такое расхождение оборачивается переделкой. Мы начинаем проектирование с формализации требований в одном документе: что система делает, для кого, с какими ограничениями и нефункциональными требованиями к скорости, нагрузке и доступности. Когда трактовки сняты до кодинга, спорных мест на разработке становится в разы меньше, а оценка сроков перестаёт быть гаданием.

Проблема вторая: стек выбирают по привычке, а не под задачу

Редакцию Битрикс, серверное окружение и архитектурный подход часто берут наугад или по принципу «как делали в прошлый раз». Через год проект упирается в потолок: выбранная редакция не тянет нужный функционал, окружение не масштабируется, а переход на другую конфигурацию стоит как новый проект. Мы обосновываем выбор стека под ваши нагрузки, бюджет и горизонт развития, сравнивая редакции и окружения по конкретным сценариям вашей задачи, а не по абстрактным сравнительным таблицам. Это решение фиксируется в документах с аргументацией, чтобы и вы, и любая будущая команда понимали, почему выбран именно такой путь.

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

Когда структуру базы и модель сущностей придумывают в процессе написания кода, переделки растут как снежный ком. Добавили свойство — пришлось переписать выборки. Изменили связь между сущностями — поехали фильтры и отчёты. Мы заранее рисуем схему данных, модель сущностей и карту компонентов, согласуем их до начала разработки и только потом отдаём в работу. Это не бюрократия, а экономия: правка схемы на этапе проектирования стоит абзаца в документе, а та же правка на проде — недели работы команды и риска для боевых данных.

Проблема четвёртая: нагрузку никто не считает до запуска

Система, которая прекрасно работает на демонстрации, ложится в первый же пик, потому что пиковые сценарии никто не моделировал. Мы делаем нагрузочные расчёты по ключевым сценариям ещё на этапе проектирования: оцениваем число пользователей, пиковые периоды, объём каталога и частоту операций, находим потенциальные узкие места и закладываем кеширование, очереди и точки масштабирования. Даже когда точных цифр трафика ещё нет, мы строим расчётные сценарии с запасом на основе бизнес-ориентиров, чтобы архитектура изначально проектировалась под рост, а не переделывалась под него позже.

Как устроен наш процесс проектирования

Мы работаем по отлаженной методике, и на каждом шаге у вас есть точка контроля и согласования.

• Установочная сессия. Разбираем задачу, ограничения и нагрузки, фиксируем бизнес-цели и предлагаем объём проектных работ, соразмерный сложности проекта.
• Анализ требований. Собираем и формализуем функциональные и нефункциональные требования, ограничения и пользовательские сценарии в едином документе.
• Выбор стека. Обосновываем редакцию Битрикс, серверное окружение и архитектурный подход под вашу нагрузку и интеграции.
• Схема данных и компонентов. Проектируем модель сущностей, структуру базы и карту модулей со связями между ними.
• Нагрузочные расчёты и интеграции. Считаем пиковые сценарии, закладываем кеш, очереди и масштабирование, описываем контракты обмена с 1С и внешними сервисами.
• ТЗ и план реализации. Собираем техническое задание и дорожную карту по этапам с вехами, зависимостями и оценкой сроков.

Когда проектирование окупается, а когда избыточно

Отдельный этап проектирования оправдан, когда цена ошибки на разработке высока: сложная бизнес-логика, нагруженный каталог, несколько интеграций, требования к доступности и сжатые сроки. В таких проектах проектирование окупается уже на первой итерации — за счёт того, что переделки и спорные трактовки сняты заранее, а оценка сроков и бюджета становится точной. Для небольшого типового сайта развёрнутое проектирование избыточно: достаточно короткого ТЗ и аккуратной разработки. Поэтому мы не навязываем тяжёлый этап там, где он не нужен, и честно говорим об этом на установочной сессии — объём проектных работ всегда соразмерен сложности и рискам конкретного проекта.

Частые возражения — и честные ответы

«Проектирование — это потеря времени, давайте сразу кодить». На простом проекте это правда, и мы так и скажем. На сложном — наоборот: две-три недели проектирования экономят месяцы переделок и делают разработку предсказуемой. Этап не задерживает проект, а убирает из него самый дорогой риск.

«Боюсь получить красивую презентацию вместо рабочих документов». На выходе вы получаете не слайды, а пакет, по которому реально разрабатывают: формализованные требования, схему данных, карту интеграций, ТЗ и план по этапам. Эти документы можно передать любому подрядчику и получить однозначную оценку — это и есть проверка качества проектирования.

«А если по ходу разработки требования изменятся?». Проектные документы — это не догма, а основа, к которой удобно возвращаться. Когда требования меняются, мы корректируем схему данных, ТЗ и план, оценивая влияние правки на сроки и бюджет. Именно потому, что архитектура зафиксирована, цену изменения видно сразу, а не в конце проекта.

«Дешевле заказать проектирование там же, где разработку». Часто да, и мы готовы вести проект целиком. Но ценность нашего проектирования в том, что документы остаются у вас и не привязывают к подрядчику: реализовать систему можно нашей командой или передать ТЗ любой другой — без потери смысла и без переписывания заново.

Логика реальных проектов: чему учат наши архитектуры

За двести с лишним спроектированных систем мы вывели несколько закономерностей. Первая: большинство срывов сроков на разработке родом не из кода, а из непроработанных требований — поэтому формализация требований важнее красивых диаграмм. Вторая: узкое место под нагрузкой почти всегда одно и предсказуемо, если посчитать сценарии заранее, а не ловить его на проде. Третья: интеграции с 1С и внешними сервисами — самая частая причина срыва сроков в середине проекта, поэтому их контракты мы описываем до старта, а не оставляем на потом. Показательный пример из практики — архитектура B2B-портала с обменом с 1С: мы спроектировали схему данных, карту интеграций и нагрузочную модель, и разработка прошла без переделок ядра, а оценка сроков оказалась вдвое точнее обычного. Другой случай — расчёт нагрузки и стека для каталога на миллион позиций: посчитали пиковые сценарии, нашли двенадцать узких мест и заложили кеширование и очереди, и каталог держит трафик распродаж без просадок с четырёхкратным запасом по нагрузке.

Чем мы отличаемся от подрядчика, который «тоже пишет ТЗ»

Формальное ТЗ часто пишут ради галочки в договоре: пара страниц общих фраз, по которым невозможно ни оценить, ни реализовать систему однозначно. Мы относимся к проектированию как к инженерной работе: за каждым документом стоит обоснование, схема данных проверяется на реальных сценариях, нагрузка считается по числам, а контракты интеграций описаны так, что подрядчик на стороне 1С сразу понимает формат обмена. Десять лет работы со сложными проектами на Битрикс означают, что мы знаем подводные камни платформы и не учимся на вашем проекте. Над задачей работают архитектор и системный аналитик, при необходимости подключаем специалиста по интеграциям и DevOps-инженера для нагрузочных расчётов, а вы общаетесь с одним ответственным за проект.

Что вы теряете, пропуская проектирование

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

Проектирование B2B-портала: на что смотрим особо

B2B-портал — один из самых требовательных к архитектуре сценариев, потому что в нём слой бизнес-логики толще, чем у обычного сайта. Персональные цены и прайс-листы под клиента, личные кабинеты с балансом и документами, роли и согласования, ограничения видимости каталога по группам — всё это нужно спроектировать так, чтобы система оставалась быстрой и управляемой при росте числа контрагентов. На этапе проектирования мы отдельно прорабатываем модель прав доступа и ценообразования, потому что именно здесь чаще всего возникают переделки, если логику придумывать на ходу. Заранее описанные контракты обмена с 1С по номенклатуре, остаткам, ценам и заказам убирают самый частый источник срыва сроков на таких проектах.

Проектирование Highload-каталога

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

Давайте обсудим ваш проект

Расскажите о задаче, нагрузках и интеграциях на бесплатной установочной сессии — мы покажем примеры схем данных и ТЗ из похожих проектов, оценим объём проектных работ под вашу систему и пришлём смету в течение рабочего дня. Вы получите понятный план проектирования без обязательств и сможете спокойно решить, нужен ли отдельный этап в вашем случае. Проектирование архитектуры на 1С-Битрикс — это управляемый способ убрать из сложного проекта самый дорогой риск ещё до того, как он успеет стоить вам денег.