Введение

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

Есть два варианта использования Bitrix Framework: "простой" и "сложный". Простой - обычный сайт, без магазина. Магазин - это более сложно, независимо от платформы. Если разработчик делал простые сайты, а потом начинает делать магазин, то ему, возможно, только с неделю нужно осваивать штатный функционал магазина.

Работая с Битрикс, нужно в первую очередь понимать, что можно выжать из стандартных компонентов и шаблонов, а что придётся дописывать.

  Простой сайт

Модель простого сайта и что должен предусмотреть проектировщик при реализации такого проекта.

В случае простого сайта не производится больших объёмов работ. Как правило, это: создание кастомных шаблонов компонентов, создание структуры сайта, шаблона сайта, несколько инфоблоков. Иногда создаётся кастомная форма добавления элемента инфоблоков.

  Сайт с объёмным контентом

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

Для хранения большого объёма данных рекомендуется использовать Облачное хранилище. Весь большой контент рекомендуется хранить там.

Для организации поэтапной работы над контентом рекомендуется использовать Документооборот и Бизнес процессы

  Много данных в инфоблоках

Под "много данных" понимается сотни тысяч и миллионы элементов.

Такой проект "тяжёл" для административной части. Рекомендуется не использовать опцию Совместный просмотр разделов и элементов в настройках модуля Информационные блоки (и настройках самого инфоблока) и обязательно разносить инфоблоки по типам.

Обязательно для таких проектов необходимо:

• Спроектировать модель данных в инфоблоках. Необходимо понять, где нужна денормализация, где - агрегация, где кеширование.
• Описать и реализовать основные запросы к данным из публички (иногда админки). Нужно понять цепочки использования. Например, клиент планирует получать регулярно список новостей (или список элементов в каталоге), и редко (раз в месяц) строить выборки, например, по продажам. Следовательно нужно обеспечить быструю обработку частых запросов, в нашем случае: просмотр списков новостей (каталога), просмотр разделов каталога.
• Реализовать соединение выборок из инфоблоков (joins). Нужно спроектировать модель соединения данных из инфоблоков. В крайних случаях использовать прямые запросы в БД. НО перед этим надо попытаться использовать все доступные средства API.
• Пользовательские свойства. Скорее всего, они будут не совпадающими у инфоблоков, так как контента много и он наверняка разнотипный.
• Кастомные страницы административной части к инфоблокам. При больших объёмах есть смысл в таком проектировании.
• Управляемое и эффективное кеширование данных.
• Экспорт/импорт - JSON, XML, REST, очереди, инкременты.

  Много ролей

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

На таком проекте практически всё делается штатными средствами, надо только понять систему уровней доступа к модулям, папкам, файлам:

• Настраиваем группы и учетные записи пользователей. Настраиваем параметры безопасности группы.
• Настраиваем уровни доступа и доступ к модулям.
• Включается проактивная защита, безопасная авторизация, а лучше - одноразовые пароли.
• Тщательное тестирование складывающейся системы доступа.
• В процессе эксплуатации не забывать отслеживать процесс изменений в системе.

  Много кода

Сложный проект, когда функционал выходит за стандартные возможности Bitrix Framework. Основная опасность: желание залезть в ядро Bitrix Framework и изменить его. В этом случае либо все изменения затрутся при обновлении, либо придётся отказаться от обновлений системы. Битрикс поддерживает обратную совместимость API, и любой проект может спокойно обновиться и получать новый функционал.

Кастомизируются или создаются компоненты. Создаются собственные модули с интерфейсом настройки, где хранятся общие классы, библиотеки. Определяем обработчики событий, которые могут менять поведение системы в нужную вам сторону, и пишем в техподдержку Bitrix Framework, если событий не хватает. Создаем свои страницы административного раздела.

В таких проектах ответственность лежит полностью на разработчиках, за Bitrix Framework не спрячешься, надо внимательно рассматривать вопросы производительности, безопасности, аудита.

  Интеграция с внешними системами

Задача потребует нетривиального программирования. Используется модуль Веб-сервисы. Если не хватает функционала, то используя REST, SOAP, JSON, XML-RPC API, дорабатываем нужный функционал. Далее реализуете систему синхронизации.

Если данных очень много, то есть смысл создать свои таблицы в MySQL и хранить данные там.

В проектах такого уровня разработчики должны представлять себе администрирование систем. Так, при работе с веб-сервисами нужно понимать XML, TCP-IP, FTP. Как пойдут пакеты, где что пропадает. И кроме этого, в группу разработчиков надо подключать квалифицированного сисадмина как можно раньше.

  Веб-кластер

Веб-кластер позволяет решать множество задач. При этом в коде вашего проекта ничего делать не нужно, это штатная функция Bitrix Framework.

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

Нужно подумать о логике восстановления на базе требований SLA. Надо понять, как сделать так, чтобы максимум 2 минуты система была недоступна. Последнее - резервное копирование. Нужен отдельный регламент.