Уже довольно давно решая задачи проектирования веб-приложений, или веб-ресурсов я использую подход при котором проектирую логику работы исходя из предметной области к которой будет относится веб-приложение. Этот подход ни разу меня не подводил, и зачастую результат работы всегда меня удовлетворял (насколько вообще результат работы может удовлетворять — ведь всегда кажется, что можно сделать еще чуть чуть лучше, и процесс улучшения может быть бесконечным). Однако иногда среди коллег мне приходится встречать мнение, что проектирование с использованием 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 не нужны. Они нужны, и во многих случаях экономят силы, время и деньги. Но если проект отличается от «домашней странички» — скорее всего проектирование с учетом предметной области будет эффективнее.