Проектування архітектури проекту на 1С-Бітрікс

Проектування архітектури проєкту на 1С-Бітрікс

Архітектурні рішення в Бітрікс-проєкті приймаються один раз — і живуть з проєктом роками. Вибір між монолітним шаблоном і компонентною архітектурою, між зберіганням даних в інфоблоках та HL-блоках, між стандартними компонентами і кастомною розробкою — кожне з цих рішень визначає вартість підтримки, можливість масштабування та швидкість додавання нових функцій через 2–3 роки. Проектування архітектури — це фаза, яку не можна пропускати, якщо проєкт планується як довгостроковий.

Шари архітектури Бітрікс-проєкту

Бітрікс має кілька рівнів, і рішення на кожному з них впливають на інші.

Рівень даних: інфоблоки, HL-блоки, користувацькі таблиці

Інфоблоки (b_iblock_element, b_iblock_element_property) — гнучкий інструмент, але з ціною: EAV-схема погано масштабується на великих обсягах. Ключові рішення на цьому рівні:

• Які дані зберігаються в інфоблоках, які — в HL-блоках, які — у власних таблицях через D7 ORM (\Bitrix\Main\ORM\Data\DataManager)
• Структура типів інфоблоків та їх групування
• Схема торгових пропозицій: один інфоблок офферів на все або окремі за категоріями

Рівень логіки: компоненти vs. власний код

Стандартні компоненти Бітрікс (bitrix:catalog.section, bitrix:sale.order.ajax, bitrix:form) покривають типові сценарії. За їх межами починається вибір: розширювати наявний компонент через шаблон, створювати кастомний компонент (CBitrixComponent) або писати логіку в контролері D7 (\Bitrix\Main\Engine\Controller).

Критерій: якщо бізнес-логіка специфічна для проєкту і не є повторно використовуваною — вона не має бути в шаблоні компонента. Шаблон — це лише представлення.

Рівень кешування

Архітектурне рішення — які дані кешуються і як інвалідуються. Варіанти в Бітрікс:

• BXCache/CPHPCache — файловий кеш для компонентів
• TaggedCache (\Bitrix\Main\Data\TaggedCache) — інвалідація за тегами
• Cache D7 (\Bitrix\Main\Data\Cache) — уніфікований кеш з підтримкою memcached/Redis
• Композитний кеш — статичний HTML для анонімних користувачів

Рівень фронтенду

Бітрікс підтримує кілька підходів: класичний PHP-шаблон з jQuery, Бітрікс-компоненти з BX.ajax, і сучасний стек — Vue/React через REST API або компоненти з bitrix:ui.*. Вибір впливає на підтримуваність: фронтенд-розробник, який прийде на підтримку, повинен орієнтуватися в тому, що ви вибрали.

Багатосайтовість та мультирегіональність

Якщо проєкт охоплює кілька регіонів або мов, архітектурне рішення приймається на старті. Бітрікс підтримує:

• Кілька сайтів в одному ядрі зі спільною БД (b_site)
• Мовні версії через механізм languages модуля main
• Регіональні сайти з різними доменами та спільним контентом

Неправильний вибір (наприклад, різні каталоги для кожного регіону замість одного з регіональними цінами) призводить до дублювання даних і проблем синхронізації.

Кейс: переробка архітектури e-commerce проєкту

Дистриб'ютор промислового обладнання, 2019 рік. Проєкт розроблявся без явного архітектурного рішення: 4 інфоблоки каталогу для різних категорій товарів, кожен зі своїм набором властивостей-рядків, користувацька логіка в init.php, шаблони компонентів з бізнес-логікою всередині.

До 2022 року: 45 000 елементів сумарно, додавання нової властивості вимагало змін у 4 місцях, фільтр не міг працювати за властивостями з різних інфоблоків, обмін з 1С — кастомний скрипт на 2 000 рядків без документації.

Що зробили при рефакторингу:

1. Об'єднали 4 інфоблоки каталогу в один з єдиною схемою властивостей через HL-блоки
2. Перенесли бізнес-логіку з шаблонів у D7-компоненти та сервісні класи в local/lib/
3. Логіку в init.php розбили на обробники подій з реєстрацією через AddEventHandler
4. Налаштували фасетний індекс на єдиному інфоблоці — фільтр почав працювати коректно
5. Стандартний обмін з 1С через CommerceML замінив кастомний скрипт

Документи, що виробляються на етапі проектування

• Діаграма структури даних: інфоблоки, HL-блоки, зв'язки
• Схема компонентного складу сторінок
• Схема кешування та інвалідації
• Архітектура інтеграцій: 1С, CRM, сторонні сервіси
• Рішення щодо багатосайтовості та мультимовності
• Обґрунтування вибору редакції та модулів Бітрікс

Строк проектування: від 1 тижня для невеликого проєкту до 4–6 тижнів для enterprise-проєкту з кількома інтеграціями та мультисайтовою структурою.