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

Традиционные CMS ограничены в бизнес-логике, enterprise-фреймворки — в скорости запуска. DST Platform позиционирует себя как решение, устраняющее этот разрыв. Рассмотрим её архитектуру объективно, без прикрас и умолчаний.

Двойная архитектура: не компромисс, а синтез

Сердце платформы — интеграция двух доменов в едином ядре: - Социальный слой: группы, лента активности, комментарии, фотоальбомы, рейтинги. Логика, проверенная в высоконагруженных сообществах. - Бизнес-слой: маркетплейс, заказы, платежи, тендеры, управление продавцами. Архитектура, ориентированная на транзакции и процессы. Ключевой технический факт: оба слоя используют общие подсистемы — единую модель пользователя (`cmsUser`), систему прав (`cmsPermissions`), менеджер событий (`cmsEventsManager`). Это не «плагин поверх CMS», а проектирование с нуля под гибридные сценарии. Пример: отзыв о товаре автоматически попадает в ленту активности, рейтинги продавца влияют на видимость в каталоге, геолокация из профиля пользователя применяется при фильтрации предложений. Связность достигается не через API-интеграции, а через общую предметную модель.

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

Платформа не навязывает единственный путь. Разработчик сам определяет глубину вмешательства: - Декларативный уровень: через административный интерфейс создаётся тип контента («Каталог оборудования», «База знаний»). Система генерирует формы, шаблоны, интеграцию с поиском, SEO, правами доступа. Подходит для CRUD-сущностей без нетривиальной логики. Экономия времени — от часов до дней. - Императивный уровень: создание кастомного компонента с контроллером, моделью, шаблонами. Полный контроль над запросами, бизнес-процессами, API. Используется для ядра маркетплейса, платежных шлюзов, сложных алгоритмов. - Точка стыка: система хуков (`cmsEventsManager`). Можно модифицировать данные сгенерированного типа контента (например, добавить поле «модифицировано» перед сохранением), не касаясь ядра. Это снижает риски при обновлениях и сохраняет читаемость кода. Такой подход позволяет начать с прототипа за час, а затем постепенно «дозакручивать» сложность, не переписывая проект с нуля.

Технические решения: прагматизм вместо догм

- Модель данных: отсутствие ORM в классическом понимании. `cmsModel` выступает как утилитарный слой с методами `getItems()`, `filter()`, `insert()`. SQL-запросы прозрачны, оптимизация — в руках разработчика. Это снижает накладные расходы, но требует ответственности за безопасность (платформа предоставляет подготовленные запросы и фильтрацию). - Событийная архитектура: хуки вроде `content_before_update` позволяют компонентам взаимодействовать без жёстких зависимостей. Это упрощает создание расширений и интеграций, но требует документирования событий для командной работы...

#DST #DSTGlobal #ДСТ #ДСТГлобал #DSTplatform #ДСТПлатформ #ДСТМультивендор #DSTмультивендор #DSTmarketplace #DSTМаркетплейс #маркетплейс #разработка #CMS #CMF #framework #Фреймворк

Подробнее: https://dstglobal.ru/products