Разработка модульной системы

[Константин Рейдо]

Добрый день.

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

Может rails не самый подходящий инструмент для этого?

[Alex Vasyutin]

Привет,

А что вкладывается в понятие "модуль" и "ядро"? 

Собственно говоря рельса и есть ядро, модули можно оформлять в виде гемов. Devise и Cancan чем не модули для авторизации и аутентификации?

-- 

Alex Vasyutin

Skype: alexander.vasyutin

Sent with Sparrow

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
 
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror...@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

[Vitaly Kurennov]

Модули мы делали в виде isolated engines. Ядро - то же engine, но не isolated. И все он в виде гемов. Модули подключают ядро как зависимость и таким образом имеют доступ ко всему функционален ядра

вторник, 31 января 2012 г. пользователь Alex Vasyutin <alex.v...@gmail.com> писал:

--
С уважением,
 Виталий Куреннов (mailto:vkur...@gmail.com)

[Константин Рейдо]

Да теперь вижу что нужно использовать engine буду разбираться с этим вопросом. Как я понял можно engine обернуть в gem.

Немного не понял каким образом работает схема. Что является контейнером в который все подключается? Если и ядро тоже engine, или это просто rails 3 приложение?

[Max Lapshin]

2012/1/31 Константин Рейдо <konstant...@gmail.com>:

> Немного не понял каким образом работает схема. Что является контейнером в
> который все подключается? Если и ядро тоже engine, или это просто rails 3
> приложение?
>

Совершенно точно, что для хорошей модульной системы обязательно нужна
Общая Шина Данных!

[Михаил]

Enterprise service bus же! Когда уже интегрируем soap и rest? Недавно открыл для себя прекрасный мир BPEL при правильно построен ной конвергентной модели - даже кодить не надо, модули сервис-ориентированной архитектуры превращаются в настоящую Платформу Развертывания Сервисов!

Ол хаил Ентерпрайз!

По моему, слишком абстрактный вопрос.
--
С уважением, Михаил Бараблин.

31.01.2012, в 18:44, Max Lapshin <max.l...@gmail.com> написал(а):

[Zabazhanov Arkady]

Rails + Engines. Это лучшая реализация модульной системы, которую я видел.

http://bokov.net/lj/cloud_computing_bullshit_bingo.jpg

31 января 2012 г. 22:08 пользователь Михаил <madbo...@gmail.com> написал:

[Vitaly Kurennov]

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

Кстати, рельсы при создании engine, сами делают их как gem. Отличие isolated от простого engine в том, что простой engine включает все свои модели, контроллери и т.п. на том же уровне, что и само приложение. Можно, наверное, тогда ядро и не упаковывать в отдельный engine, но тогда в модулях придется requir'ить необходимые классы. В случае же, если ядро сделано отдельным гемом, то его надо только добавить в зависимости и один раз прописать в lib/<engine name>/engine.rb. И после этого все классы из ядра станут доступными в модуле

вторник, 31 января 2012 г. пользователь Zabazhanov Arkady <kinw...@gmail.com> писал:

[Alex Dmitriev]

Все эти ядра и модули - это такая знаете тема, в ней можно блуждать и
выдумывать любые решения, от простого разбиения по папкам до фабрики
из тысячи классов для вывода hello world из XML

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

31 января 2012 г. 21:44 пользователь Vitaly Kurennov
<vkur...@gmail.com> написал:

--
Alex V. Dmitriev
Jabber/GTalk/MSN/AIM: rene....@gmail.com
Skype: rene-dekart
Blog: http://railorz.ru

[Константин Рейдо]

В какой-то момент руководство посетила мысль что нужно нам свою CRM систему сделать. Так как заказчики разные и кому-то нужны заказы и задачи, кому-то нужны слушатели курсов и преподаватели и так далее то захотели чтобы такие сущности можно было вынести в модули и подключать для каждого типа CRM или использовать совместно. Набор таких модулей будет объединяться в так называемые DomainCRM например для обучения это будут преподы и учащиеся, для бизнеса это будет заказы и исполители. DomainCRM - это обстрактный набор модулей, просто вот такой вот набор может удовлетворить потенциального заказчика из определенной области. Дальше нужно под каждого заказчика еще кастомизацию заложить в архитектуру. Вот такая вот задача стоит.

Из того что понял за это время. Нужно использовать rails + engine. Сейчас еще не разбриался но вроде архитектурно можно посмореть в spree https://github.com/spree/spree

[Alex Dmitriev]

Константин,

Вот теперь все становится на порядок яснее.

Я бы посоветовал сделать следующее: вынести в модули только реально
общие части - авторизацию, отправку сообщений, управление правами и
так далее. Модули делать используя rails engine. А весь функционал,
специфичный для конкретных заказчиков, делать непосредственно в самом
приложении. Если какой-то функционал будет повторяться от заказчика к
заказчику - тоже выносить в модули, но только тогда когда как минимум
три проекта будут делить общий функционал - для двух проектов проще
патчами перекидывать изменения

Еще один вариант - это не выносить ничего в модули, а сделать некий
абстрактный скелет с общим функционалом и от него делать клоны. Git
позволяет полностью клонировать репозиторий в новый и потом
портировать изменения из общего репозиторя (core) в репозиторий
конкретного заказчика через git pull. Можно делать общие системные
изменения в главном проекте и потом портировать в клиентские, а
кастомизации делать непосредственно в клиентском репозитории.

1 февраля 2012 г. 17:52 пользователь Константин Рейдо
<konstant...@gmail.com> написал:

[Andrey Voronkov]

Как раз у меня та же проблема - если есть подробный материал по тому, как это можно организовать (поддержку разных версий приложения под разных кастомеров, но эти версии произрастают из общей "платформы") - поделитесь ссылочками.

1 февраля 2012 г. 17:44 пользователь Alex Dmitriev <rene....@gmail.com> написал:

[EXO]

On 1 фев, 19:44, Alex Dmitriev <rene.dek...@gmail.com> wrote:
> Если какой-то функционал будет повторяться от заказчика к
> заказчику - тоже выносить в модули, но только тогда когда как минимум
> три проекта будут делить общий функционал

+1
CRM на российском рынке это такая тема... Короче, каждый вкладывает в
эти буквочки свой смысл (и свято верит, что "это и есть CRM"). А
потому, надежда заранее выделить универсальные модули прикладной
логики - в данном случае иллюзия. Универсальным, в данном случае,
будут сменно "системные" (условно) элементы функционала. Их и стоит
выделять.

[Max Lapshin]

Моё мнение такое, что задача «спроектировать систему модульной» по
сути равносложна задаче «написать корректный алгоритм по человеческому
описанию», что как мы знаем принципиально невозможно вплоть до точных
доказательств.

Помимо таких явных проблем типа меняющести бизнес-логики на ходу, есть и другое.
Я не просто так рассказал про Общую Шину Данных. Если при
проектировании системы произнести эти слова (ОШД), то надо
расходиться в отпуск, возвращаться и делать всё с нуля. Ни одна
система на ОШД не взлетела.

Проблема мне видится в том, что пока в голове сидит ОШД, автор кода
мыслит кирпичиками бизнес-логики, которые
соединены стрелочками. Самое плохое в этом то, что ни одна система так
не устроена!

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

Это лирика. Теперь совет. Совет такой: начать писать то, что
получается. По мере написания рефакторить, унифицировать и
если будет всё ок, то через год что-то начнет вырисовываться.

Моим признаком неплохой архитектуры является вот что: когда появляется
бизнес-требование и его получается реализовать в коде
в рамках имеющейся инфраструктуры — это неплохая архитектура.

Беда всех «модульных» систем в том, что на практике при написании
любого, даже простого модуля, приходится перекраивать архитектуру,
потому что концепция ОШД не подразумевала _такой_ коммуникации модуля
с остальными кирпичиками.

[Alexey Petrushin]

> CRM на российском рынке это такая тема... Короче, каждый вкладывает в

> эти буквочки свой смысл (и свято верит, что "это и есть CRM")

Ха-ха-ха, хотел написать тоже-самое но подумал что не буду уводить дискуссию в сторону :)

Но ЦРМ все-таки боль-меннее стабильный, думаю что самый веселый термин это "Документооборот" - под ним понимают вообше что угодно.

Нуууу, шина данных (ЕСБ) по-моему классная штука, проблемы с ней потому-что пытаются использовать не там где не нужно. Это как производсвенный конвейр, который нужен только в маштабах заводов типа БМВ и прочих монстров. Нужно быть готовым к куче сложностей, и морю влитых усилий и бабла чтобы он заработал. А когда его пытаются использовать в мелком и среднем производстве сложности на его использование себя просто не оправдывает.

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

[Alex Dmitriev]

По мотивам этого обсуждения написал постинг в блог:

http://railorz.ru/articles/157-customization/

Топикстартеру на заметку. Все из личного опыта.

1 февраля 2012 г. 18:44 пользователь Alex Dmitriev
<rene....@gmail.com> написал: