Я работаю во внутреннем ИТ-отделе компании, в которой работает около 10 магазинов различной сложности. Кодекс магазинов был написан за последние 8 лет, в каждом магазине растут новые отцы и папы от стебля (думаю, это делает их кустарником?)
Потребность во все более сложных скидках, кампаниях и мониторинге пользователей быстро растет, а также быстро меняется (вы никогда не знаете, что они придумали). Поэтому мы решили написать новую систему с нуля и объединить различные магазины, чтобы они работали на одном и том же основном коде. Мы рассмотрели .NET, но из-за того, что требования к дизайну меняются так быстро, мы более или менее решили попробовать Rails. Но у нас есть некоторые неопределенности / вопросы о рельсах.
Подходят ли Rails (стек) для построения структуры магазина и кто должен это организовывать?
У нас работает около 10 магазинов, некоторые из которых очень похожи, только отличаются по стилю, в то время как другие выделяются по функциональности, потоку и содержанию. Но за бизнес-логикой все то же самое. Функциональность магазинов в значительной степени одинакова. В качестве примера на странице оформления заказа в одном магазине может отображаться подробная информация о НДС, скидках, P & P и т. Д., Тогда как в другом может отображаться только необходимый минимум.
Какой подход вы бы выбрали? Будете ли вы создавать и поддерживать работающий магазин шаблонов с функциональным набором магазинов. По мере разработки новых функций объединять код с другими магазинами? Звучит немного громоздко.
В примере со страницей оформления заказа views будет отличаться от магазина к магазину, но controllers и models останутся прежними, пока вы выводите конфигурации, такие как типы методов оплаты и т. Д. на.
С этой точки зрения было бы более разумным просто создать репозиторий представлений и конфигураций для каждого магазина, а затем сохранить код модели и контроллера в отдельном репозитории.
Можно было бы организовать представления в соответствии с магазином, сохраняя все ресурсы в одном хранилище /views/shopname/Product. Будет ли это иметь смысл?
Что ты думаешь? как бы ты это сделал? Приведет ли такая работа к рельсам много проблем?
Наша система кампаний / скидок постоянно усложняется, как с графическим интерфейсом, так и с бизнес-логикой. (с этой точки зрения Rails кажется интересным с его быстрым поворотом). Наши скидки основаны на свойствах, и эти свойства хранятся в строке базы данных.
Внесение изменений в требования к оформлению скидки - настоящая головная боль. Таким образом, мы постепенно заменяем эту систему, основанную на свойствах, системой, которая для каждой скидки присоединяет класс (PHP) и конфигурацию, чтобы каждый тип скидки имел свой собственный класс, и каждое использование такой скидки может указывать некоторые значения для этого класса для работы данный текущий контекст (в основном: что находится в корзине)
В рельсах какой подход вы бы выбрали?
В рельсах вы можете легко расширить свою модель (скидку) еще одним свойством, мигрировать, и вы готовы (возможно, немного упростили). Не могли бы вы написать базовый класс скидок, основанный на нескольких базовых свойствах, а затем написать модули, которые подключаются (расширяют) этот класс на случай, если вам потребуется более продвинутая функциональность?
Конкретно, что это будет в терминах Rails как помощник?
Некоторые из этого поста могут быть немного неясными. Пожалуйста, задавайте вопросы. Также я нахожусь в процессе изучения Rails, поэтому извините, если вы не используете правильные термины или я пропустил некоторые из основных идей Rails.
Спасибо
Michael