В этой статье я расскажу о разработке и эволюции технической части браузерной игры «Пути Истории».
Уделю внимание выбору языка программирования, базы данных, технологии и архитектуры. Расскажу о хостинге.

Пути Истории — это массовая браузерная стратегическая игра. Проект начинался с энтузиазма одного человека и вырос до серьзного проекта с немалой аудиторией.

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

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

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

Итак, в своей первой статья я сделал несколько предположений об архитектуре предметной области в CMF/CMS системах. Тогда я сделал предположение об объектной модели я связанном с нею сервисе, который умел обрабатывать входящие запросы и выдавать нужный результат на основании внутренней структуры модели.

Сегодня, сейчас, я бы хотел коснуться вопроса непосредственного использования такой системы в существующем фреймворке Mozart, не так давно впущенном компанией ADV под лицензией GPLv3.

Основой API Mozart'а служат newt-контейнеры. Newt — это XML-контейнер (в XML-фрагменте), который специальным образом обрабатывается XML-парсером. Newt может быть как одиночным тэгом (закрытым тэгом <newt />), так и контейнером (содержит в себе другие контейнеры (newt'ы, инструкции)). Аналог newt'а — это функция, задачей которой является произвести какие-то действия (и вернуть результат, если требуется).

Практически любая информационная система характеризуется наличием системы хранения и оперирования данными. Возьмем, к примеру, обычные веб-сайты. Для их создания обычно используются какие-либо готовые системы (фреймворки или уже готовые CMS), в которых изначально уже заложена какая-то концепция по работе с данными, установившаяся предметная область. Обычно, если разработчик хочется добавить на сайте раздел новостей, он добавляет в интерфейсе CMS компонент, информационный блок, шаблон и т.п. Суть всех этих конструкций одна — создать сущность в БД для хранения (либо каком-то ином хранилище). В итоге имеется реляционная база данных и, зачастую, какой-то объектно-ориентированный обвес, реализующий связку объект-атрибуты-свойства-методы — реализуется предметная область.

Ниже пойдет речь об одном из вариантов архитектуры предметной области. Статья базируется на опыте работы в компании ADV, которая применяет подобные методы в разработке веб-проектов. Сложность изложенного материала позволяет понять его не только разработчикам ПО, но и веб-мастерам, которым надо периодически дорабатывать существующие веб-проекты, добавляя в них новые данные.

Самые простые системы позволяют лишь организовать хранилище, к которому разработчик в дальнейшем обращается и делает всю необходимую работу по обработке данных сам. В таком хранилище есть лишь объект, поля и данные. В более продвинутых системах между объектами появляются связи. Следующий уровень развития — взаимодействие объектов (триггеры, методы и т.п.), а так же наличие программной подсистемы, снимающую с разработчика часть забот по обработке данных.

Сам по себе я довольно ленивый программист. Наверно поэтому меня долгое время преследовала мысль о создании инструмента, пригодного для решения широкого круга задач небольшого предприятия. Так появился архитектурный шаблон корпоративной информационной системы, который я первым делом применил в разработке web-платформы предприятия в виде CMS/CMF OpenKit.net.

Знали ли разработчики Livescript из Netscape о том, какое влияние окажет их язык, позже переименованный в Javascript, на лицо интернета — веб-сайты, или, может быть, они твердо на это рассчитывали, но факт остается фактом — Javascript на сегодняшний день является одним из самых важных и распространенных языков в мире.

В то время, как на стороне сервера трудится разношерстная компания языков в лице php, perl, python, ruby, .net, java и многих других, на стороне клиента Javascript существует буквально в гордом одиночестве. Фактически, из маленького дополнения к html, Javascript превратился в полноправного члена банды «html+css+js», который, зачастую, уже командует остальными, сверкая золотым браслетом с надписью «ajax» и делая недовольное лицо $( ) при случае.

Большие проекты, с долгой историей — уходящей своими корнями в 90-е, в большинстве случаев основываются на монолитной архитектуре (не касательно web — корни тянуться еще глубже). В работе я часто сталкиваюсь с подобными системами и у них всех практически одни и те же проблемы, об этом и хотелось бы рассказать сейчас.

Основная проблема

При создании не предполагает наращивания функционала. Создается «раз и на всегда» — любая «новая кровь» — не той группы и вызывает отторжение. Любое хирургическое вмешательство рано или поздно приводит к появлению «Франкенштейна» — сущности Множеств — объеденных синтетическими связями.