Проектирование и рефакторинг / Отказ от использования CMS при проектировании веб-приложений

в 10:19, , рубрики: web-разработка, архитектура по, архитектура приложений, проектирование, разработка, метки: , , , ,

Проектирование и рефакторинг / Отказ от использования CMS при проектировании веб-приложений
Уже довольно давно решая задачи проектирования веб-приложений, или веб-ресурсов я использую подход при котором проектирую логику работы исходя из предметной области к которой будет относится веб-приложение. Этот подход ни разу меня не подводил, и зачастую результат работы всегда меня удовлетворял (насколько вообще результат работы может удовлетворять — ведь всегда кажется, что можно сделать еще чуть чуть лучше, и процесс улучшения может быть бесконечным). Однако иногда среди коллег мне приходится встречать мнение, что проектирование с использованием CMS гораздо эффективнее. После последней такой беседы я решил написать статью и поделится своими мыслями с хабра-сообществом.
Я постарался описать оба подхода проектирования и как можно шире раскрыть тот подход, который использую сам.
Этой статьей я не пытаюсь доказать что использование CMS не эффективно. Оно эффективно, но по моему мнению только тогда, когда в будущий ресурс новый функционал вносить не предполагается. И когда изначальный функционал не выходит за пределы «сайта-визитки» (хотя и «визитка» порой может быть достаточно технологичной и требовать для реализации того, чего с ограниченными возможностями CMS добиться достаточно трудоемко).
Плюсы CMS:оттестированный проверенный многими разработчиками код

универсальность

простота использования

Минусы CMS:предметная область ограничена теми объектами которые предусмотрены в CMS

основная логика работы приложения определена разработчиками CMS. Внесение изменений в логику очень проблематично

излишняя универсальность (без которой сама CMS была бы бессмысленна) приводит к избыточному функционалу

Почему я предпочитаю работать в предметной области:есть возможность более чисто описать логику взаимодействия обектов предметной области

есть возможность более гибко изменять логику работы приложения

более чистый код

логика отображения, логика управления данными и бизнес-логика разделены между собой

Недостатки работы с предметной областьюизначально необходимо больше времени для создания проекта

некоторые вещи необходимо писать вручную

требования по квалификации для разработчика выше

На первых этапах при создании простого ресурса скорость разработки с применением CMS будет конечно выше. Но чем больше будет наращиваться функционал, тем больше времени нужно будет на его реализацию. К тому же в какой-то момент может появиться необходимость внесения изменений в исходный код самой CMS. А это сводит практически к нулю преимущество «надежности кода». Ведь, по сути, после этого все этапы тестирования исходного продукта (CMS) необходимо пройти заново. А такая возможность не всегда имеется.
Возможны варианты архитектуры веб-приложения

Ниже я опишу обобщенный вариант архитектуры веб-приложений с построенных с использованием CMS и с использованием подхода проектирования на основе предметной области.
Обобщенная архитектура веб-приложения при использовании CMS

В данном случае, как видно бизнес-логика, логика отображения и логика доступа к данным связанны с архитектурой самой CMS.
Таким образом что бы изменить принцип построения отображения (forntend) иногда необходимо вмешаться в архитектуру самой CMS.
Кроме того модель данных также скорее всего будет основана на объектах которыми оперирует CMS, а не объектах которые могли бы отображать суть предметной области для которой разрабатывается приложение.
Обобщенная архитектура веб-приложения основанного на модели предметной области

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

Конечно, все вышеизложенное не означает, что проект нужно писать с нуля полностью. Принципы повторного использования кода никто не отменял. И тут они тоже как никогда кстати.
Например я за время своей деятельности я разработал ряд библиотек которые использую во всех своих проектах.
Вот краткий список наиболее востребованного функционала который я использую чаще всего при разработке под веб:инициализация метаданных страницы(keywords, description)

установка canonical url

инициализация данных для Open Graph (Facebook, Vkontakte)

отправка email

безопасное получение параметров запроса (параметры из обычных url, или url с применением роутинга получаются единообразно, с уже приведенным типом)

обработка исключений

генерация интерфейса (например Dynamic Data — применяется исключительно для администрирования ресурса)

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

Исходя из различных наблюдений могу сказать, что итоговая стоимость разработки проекта, который активно развивается (то есть новый функционал появляется часто) при использовании CMS будет выше, чем у проекта, который проектируется исходя из предметной области.
Все это вовсе не означает, что CMS не нужны. Они нужны, и во многих случаях экономят силы, время и деньги. Но если проект отличается от «домашней странички» — скорее всего проектирование с учетом предметной области будет эффективнее.

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js