Архитектура и структура проекта (где живёт код)

Структура файлов и каталогов

Структура проекта важна не “потому что папки”, а потому что она отвечает на главный вопрос архитектуры: где у нас живут роли — роутинг, контроллеры, модели, представления, бизнес‑сервисы, конфиги.

Чтобы не писать общие слова, начнём с прикладной карты “где что лежит”, а затем разберём нюансы.

Карта “где что лежит”: Laravel ↔ Bitrix

Laravel: структура, заточенная под MVC (и расширяемая без боли)

Laravel из коробки даёт очень понятные “центры тяжести” (официально: Directory Structure):

• routes/ — входные точки (web/api/console). Роуты не прячутся “где‑то”, это отдельная сущность проекта.
• app/Http/Controllers/ — контроллеры, которые принимают запрос, вызывают сервис/домен и возвращают response.
• app/Models/ — модели Eloquent (если вы используете “laravel‑way” для данных).
• resources/views/ — Blade‑вьюхи: layout’ы, страницы, компоненты (про компоненты поговорим глубже в части про шаблонизацию).
• app/Providers/ — сервис‑провайдеры: место, где вы регистрируете свои сервисы/биндинги и “вшиваете” инфраструктуру в контейнер.
• database/ — миграции/сидеры/фабрики: данные и схема БД как часть кода.

Практическая мысль: Laravel не просто “разложил папки”, он подталкивает к разделению слоёв: HTTP отдельно, домен отдельно, представление отдельно.

Битрикс: структура, заточенная под “сайт из компонентов” (и требующая договорённостей)

В Битриксе точка сборки страницы исторически другая: страница/раздел собираются компонентами внутри шаблона сайта.

Базовая структура (официально: Структура директорий):

        site-root/
  local/      # ваш код и кастомизация
  upload/     # файлы
  bitrix/     # ядро

    

Но архитектурно важнее — что находится внутри local/:

1) Представления (вьюхи): шаблон сайта и шаблоны компонентов

• Шаблон сайта обычно живёт в local/templates/<site_template>/. Это аналог “глобального layout’а” и структуры страниц: шапка/подвал, общие стили, подключения.
• Шаблоны компонентов могут быть:
  • рядом с компонентом в local/components/<vendor>/<name>/templates/<template>/,
  • или переопределены на уровне шаблона сайта (частая практика для кастомизации без “форка” компонента).

Компонентный подход в деталях: Структура компонента, Шаблоны компонента, Простые и комплексные компоненты.

2) “Контроллер” в классическом понимании: чаще всего это компонент

Во многих проектах роль “контроллера” фактически выполняет компонент — в формате component.php или пары class.php + templates/ (два распространённых варианта реализации):

• получает вход (параметры, запрос),
• собирает данные (часто — через API/ORM/сервисы),
• отдаёт массив в шаблон компонента.

Здесь важная развилка архитектуры:

• если в component.php/class.php живёт бизнес‑логика — проект быстро деградирует,
• если component.php/class.php тонкий (оркестратор), а домен вынесен — проект “держит форму”.

3) “Вьюхи как во фреймворке”: D7‑контроллеры умеют рендерить представления

Если вы строите проект в более MVC‑стиле, в Битриксе можно (и это уже “официальный путь”) использовать D7‑контроллеры и возвращать HTML через renderView().

Важно: система ищет шаблон по пути вида local/modules/<vendor>.<module>/views/.... Это делает слой “представлений” в Битриксе ближе к классическому фреймворку, а не только к компонентам.

Документация: Контроллеры → Рендеринг представления (renderView).

4) Модели и бизнес‑логика: модуль как “нормальный дом”

Если вы хотите структуру уровня Laravel, самый устойчивый путь — выделять бизнес‑логику в модуль:

• local/modules/<vendor>.<module>/lib/ — классы домена, сервисы, интеграции;
• здесь же обычно живут D7 ORM‑классы (*Table и связанные сущности);
• здесь же уместны D7‑контроллеры (Engine Controller), если вы строите API/роутинг “по‑фреймворковому”.

Да, “можно и в local/lib/”, но модуль даёт границы, которые особенно нужны, когда проект растёт.

Laravel: “пакет = Composer + сервис‑провайдер”

Пакет в Laravel — это обычная Composer‑зависимость, которая может:

• добавить классы и конфиг,
• зарегистрировать сервисы через Service Provider,
• добавить роуты/миграции/команды/вьюхи.

Фундаментальный механизм — контейнер и провайдеры: Service Container, Service Providers.

Битрикс: “модуль = часть платформы со своим жизненным циклом”

Модуль в Битриксе — это “встроенная” единица системы: вы можете ставить/снимать модуль, он регистрируется, добавляет таблицы, события, настройки, админку, API.

Если вы хотите проект уровня “не один лендинг”, то модуль — зачастую лучший ответ на вопрос “куда класть бизнес‑код”, потому что он:

• изолирует доменную логику от компонентов,
• даёт структуру и границы (что особенно важно, когда в проекте 5+ разработчиков),
• уменьшает хаос обновлений и копипаста.

MVC в Laravel: “HTTP‑слой → домен → инфраструктура”

Классическая (и самая здравая) картина в Laravel выглядит так:

• Route: определяет входную точку,
• Controller: тонкий слой оркестрации,
• Service/Action: бизнес‑логика,
• Model (Eloquent) / Repository: доступ к данным,
• View / API Resource: представление результата.

Пример “как принято” (условно):

        // Controller: получает запрос и вызывает сервис
final class OrderController
{
    public function store(StoreOrderRequest $request, CreateOrder $action)
    {
        $order = $action->handle($request->validated());
        return response()->json(['id' => $order->id]);
    }
}

    

Ключ не в том, что “MVC красиво”, а в том, что Laravel поощряет разделение ответственности через предсказуемые точки расширения.

Компонентный подход в Битриксе: “страница собирается компонентами”

В Битриксе исторически центральная единица — компонент:

• он получает параметры (из шаблона/настроек),
• делает выборки/готовит данные,
• передаёт их в шаблон компонента.

Если упрощать, “страница” часто становится композицией компонентов, а “контроллер” как явная сущность может отсутствовать.

Это не плохо и не хорошо — это просто другой центр тяжести:

• плюс: удобно для CMS‑логики и контентных страниц, есть готовые компоненты,
• минус: если бизнес‑логика попадает в компоненты, проект быстро превращается в “spaghetti components”.

Практический вывод: в Битриксе особенно важно сознательно выстраивать слои, потому что платформа сама по себе “не заставляет”.

Service Container (Laravel) vs Service Locator (Bitrix): почему это вообще важно

Laravel: зависимости приходят “снаружи” (DI по умолчанию)

Laravel построен вокруг контейнера зависимостей: вы описываете, как создать сервис, а затем получаете его через:

• constructor injection,
• method injection,
• или через app(SomeClass::class) / фасады (но это отдельная тема).

Документация: Service Container, Facades.

Это даёт очень практичные вещи:

• код проще тестировать (можно подменять зависимости),
• классы имеют явные зависимости,
• меньше скрытой магии “откуда взялся объект”.

Битрикс: Service Locator как DI‑механизм (и как он реально работает)

В Битриксе Service Locator есть официально: \Bitrix\Main\DI\ServiceLocator (PSR‑11, доступен с версии main 20.5.400). Документация: Service Locator.

На практике это означает два важных “архитектурных” эффекта:

1. Вы можете регистрировать сервисы (в .settings.php ядра или в .settings.php модуля) и получать их по коду/классу — то есть у вас появляется “контейнер” и контролируемое создание объектов.
2. D7‑контроллеры умеют автовайрить зависимости: если класс не относится к встроенным “особым” аргументам и не описан в getAutoWiredParameters, система попытается взять его из Service Locator (а если не зарегистрирован — создаст напрямую).

При этом, да, в старых/типичных проектах всё ещё встречается “глобальный контекст”:

• глобальные объекты ($USER, $APPLICATION),
• статические фасады‑стайл классы (\Bitrix\Main\Application, \Bitrix\Main\Context),
• “подключи модуль и используй классы”.

Это удобно “быстро сделать”, но у этого есть цена:

• зависимости становятся неявными,
• тестирование усложняется,
• растёт связность кода и платформы.

• выносить бизнес‑логику в сервисы/классы,
• прокидывать зависимости явно (хотя бы через конструктор),
• уменьшать количество прямых обращений к глобальному контексту из домена.

Сравнительная таблица: структура и архитектура

Шкала (как и в прошлой части): от -2 до +2.