Разработка на DST Platform

Инструменты разработчика в административной панели

Что это даёт бизнесу: управление проектом ведётся из одной панели — без набора внешних утилит и отдельных договоров на инфраструктурные инструменты.

Административная панель закрывает полный цикл работы с проектом:

- Генератор компонентов — каркас нового компонента создаётся автоматически: структура файлов, стандартные контроллеры и модель.
- Встроенный FTP-клиент и файловый менеджер — работа с файлами проекта прямо из панели.
- Администрирование базы данных — просмотр и управление таблицами без сторонних клиентов.
- SSH/SFTP-доступ и почтовый сервер — управление окружением и исходящими письмами.
- Отладка, мониторинг, логирование — диагностика и наблюдение за состоянием системы в процессе разработки.

Работа с компонентами

Что это даёт бизнесу: система собирается из автономных блоков — модули разрабатываются, обновляются и заменяются независимо, не затрагивая остальное.

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

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

Каждый компонент владеет своими данными и обращается к данным других через события, а не прямые вызовы: новый модуль подключается к системе, не изменяя код существующих. Такая архитектура упрощает поддержку и позволяет заменять или выделять отдельные модули в самостоятельные сервисы по мере роста проекта.

Практическое следствие: компонентная архитектура — не догма, а стратегия эволюции. При возникновении измеримой необходимости (разные паттерны нагрузки, нормативные требования, организационное разделение команд) любой модуль выделяется в самостоятельный сервис с минимальными изменениями.

Контроллеры

Что это даёт бизнесу: предсказуемая обработка запросов и прозрачная отладка — один HTTP-запрос соответствует одному контексту выполнения, а не цепочке сервисов.

Контроллер — центральный элемент компонента, точка входа для логики. Он принимает HTTP-запрос, валидирует входные данные, обращается к модели за данными, подготавливает их к отображению и возвращает ответ: HTML-страницу, JSON для API, редирект или иной формат.

Каждый компонент может иметь два контроллера: frontend — для публичной части сайта и backend — для административной панели. Такое разделение позволяет независимо развивать пользовательские и административные сценарии, не смешивая их в одном коде.

Ключевой принцип: контроллер не пишет прямые SQL-запросы — он обращается к методам модели. Это обеспечивает безопасность (защита от SQL-инъекций встроена в модель), централизацию логики данных и возможность замены СУБД без изменения контроллеров.

Работа с моделями

Что это даёт бизнесу: безопасная и предсказуемая работа с данными — защита от SQL-инъекций, централизация логики данных и полный контроль над производительностью запросов.

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

Модель — не ORM. Модель DST Platform — это не объект отдельной записи, а утилитарный класс, предоставляющий методы для работы с таблицами базы данных. ORM (Eloquent, Doctrine и подобные) не используется: прозрачность запросов и полный контроль над SQL сохраняются. Для сложных выборок доступны прямые оптимизированные запросы — это критично для высоконагруженных систем (см. «Технологии и архитектура», раздел 3.8).

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

Работа с шаблонами

Что это даёт бизнесу: дизайн меняется без затрагивания логики, а кастомизация темы не конфликтует с обновлениями платформы.

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

Ключевой механизм — наследование тем. Дочерняя тема переопределяет только те файлы, которые действительно нужно изменить (шаблоны, стили, скрипты), а остальные наследует от базовой. Это даёт два практических следствия: кастомизация не копирует всю тему целиком и не разрастается; обновления базовой темы не затрагивают внесённые изменения. Отдельные страницы переопределяются и по URL, и по ID категории — посадочные страницы создаются без разработки.

Шаблоны содержат только HTML-разметку и минимальный PHP (условия, циклы, форматирование) — логика данных строго разделена с контроллерами и моделями. Это снижает риск ошибок при изменении дизайна и упрощает передачу проекта между командами.

Работа с CSS/JS (assets)

SEO-методы контроллера

Что это даёт бизнесу: SEO динамических страниц управляется из одного места — без ручной настройки для каждой карточки товара и категории.

Мета-данные страниц задаются в контроллерах: заголовок страницы, keywords, description, canonical, Open Graph и произвольные теги. Это позволяет управлять SEO динамических страниц — карточек товаров, категорий, городов — из единого места, а не вручную для каждой страницы.

Шаблоны мета-тегов настраиваются без кода: для каждого типа страниц задаются правила формирования заголовков и описаний, которые автоматически применяются ко всем сущностям этого типа.

Расширение через хуки

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

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

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

Подробнее о системе событий и её архитектурной роли — в разделе 3.7 «Технологии и архитектура».

Создание собственных полей

Что это даёт бизнесу: нестандартные данные бизнеса — цвет, геокоординаты, специальные форматы — вводятся штатными механизмами, без ожидания вендора и обхода валидации.

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

Автозагрузка и соглашения именования

Что это даёт бизнесу: структура кода легко читается — новый разработчик или подрядчик быстро ориентируется в проекте, а сторонние библиотеки подключаются без конфликтов с ядром.

Платформа использует собственную систему автозагрузки, основанную на соглашениях об именовании: имя класса однозначно определяет расположение файла (например, класс modelUsers находится в users/model.php). Кодовую базу легко навигировать без «приватных знаний» о проекте.

Дополнительно поддерживается загрузка классов по пространствам имён (namespaces): сторонние библиотеки подключаются без конфликтов с классами ядра и компонентов — современные практики PHP-разработки и внешние зависимости используются без риска для системы.

Рекомендации по разработке

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

Чек-лист, обеспечивающий поддержку и безопасность проекта на долгой дистанции:

1. Не изменять ядро. Кастомизация — через хуки, наследование классов и шаблоны: правка ядра осложнит обновления.

2. Работа с БД — только через модель или подготовленные запросы. Защита от SQL-инъекций встроена в стандартные механизмы.

3. Контроллер не пишет SQL. Прямые запросы должны находиться в модели; контроллер обращается к её методам. Это обеспечивает централизацию логики данных.

4. Входные данные от пользователя — фильтровать. Стандартные механизмы платформы обеспечивают фильтрацию и валидацию входящих данных.

5. Валидация форм — декларативно. Правила задаются для каждого поля: обязательность, формат, диапазон; при нестандартных данных создаётся собственный тип поля.

6. Кэширование — активно. Тяжёлые выборки кэшируются с продуманным временем жизни по типу данных.

7. Производительность — настройки по умолчанию. OpCache включён в продакшене; объединение и минификация CSS/JS — через встроенные настройки, без сторонних сборщиков.

8. Отладка — только на staging. Режим отладки включается на тестовом окружении и не влияет на продакшен.

9. Границы компонентов — через события. Взаимодействие между компонентами выполняется через события, а не прямые вызовы чужих моделей и таблиц.

Интеграции

Что это даёт бизнесу: платформа встраивается в существующий ИТ-ландшафт заказчика, а не требует его перестройки.

- REST API — для мобильных приложений и внешних систем.
- Готовые модули: платёжные шлюзы (ЮKassa, Robokassa, Т-Банк), доставка (CDEK и другие), картография, верификация, рассылки, аналитика.
- Обмен с 1С, CRM, ERP — типовой обмен реализуется штатными механизмами; кастомизированные конфигурации подключаются после анализа структуры учёта заказчика: согласование схемы обмена, настройка или разработка модуля.
- Нестандартные системы — модули интеграции разрабатываются силами DST Global или ИТ-команды заказчика: исходный код открыт и документирован.