Какую архитектуру(mvc, hmvc...) выбрать для интернет магазина?

Question

[Kokaas]

Встал вопрос на счет архитектуры.
Знаю что есть:
mvc - древний, для не больших проектов.
hmvc - более свежий вариант, для более нагруженных проектов.
Может что-то новенькое появилось и что лучше выбрать ?
Нагрузка предполагаемая около 100 000 посещений в день, максимум.
Минимальная 10 000 просмотров.

В связки будет:
nginx 1.7 (может по свежее версию)
php5.5, mysql5.5 (php 7? можно попробовать на.)
redis(для кэша, push, всяких оповещений)
Клиент написан на js.
Обмен данными асинхронный (ajax или websokets не знаю что лучше выбрать..)
да вроде бы не чего не упускаю.

REST или SOAP, склоняюсь больше к SOAP. т.к платежные системы начали переходить на SOAP и представляют любо SOAP или api.

Comments

[Kokaas]

И да, желательно что бы с ооп можно было..

Answer 1

[Сергей Протько]

Какую архитектуру(mvc, hmvc...) выбрать для интернет магазина?

CQRS + Event Sourcing.

REST или SOAP, склоняюсь больше к SOAP. т.к платежные системы начали переходить на SOAP

только REST (ну или RPC), SOAP это боль и унижение (если вы конечно не пишите и клиент и сервер на .NET)

php 7? можно попробовать на

А смысл? Потом проапдейтитесь.

Нагрузка предполагаемая около 100 000 посещений в день, максимум.

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

Обмен данными асинхронный (ajax или websokets не знаю что лучше выбрать..)

Не знаю как правильно пишется, Июнь или Июль? Ирак или Иран?. websockets помогут если у вас очень интенсивный обмен данными между клиентом и сервером. В остальном long-poling попроще. Хотя я думаю вам push-уведомления вообще не нужны.

redis(для кэша, push, всяких оповещений)

Только для кэша и можно еще как шину данных и очередь использовать.

Клиент написан на js.

А можно на чем-то другом? (языки транслирующиеся в js не в счет).

Comments

[phpus]

REST, SOAP для php на столько плохо?
Там еще 3й есть, на сколько я знаю.
api есть и хватит :D

[AlexLIn]

почему REST и SOAP это боль и унижение? slimframework + angularjs вродебы очень даже нечего

[Kokaas]

REST, SOAP это боль и унижение. Почему ? Что тут плохого?
Предлагаете как phpus api использовать ?
Шину данных : каких ?
И очередь использовать - какая? Вроде как заказы, сессии, запросы ?

[Сергей Протько]

AlexLIn: уточнил, там вообще-то завятая стояла, не перечисление а отделение двух частей предложения. Но на всякий раскрыл чуть более полно.

phpus: с SOAP везде все плохо. По началу вроде бы все не плохо, а потом боль.

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

[phpus]

Я почитал про CQRS + Event Sourcing - не правильный подход и все.
Если он новичок, это погубит магазин.

[Сергей Протько]

phpus: и да, хватит писать чушь.

[Сергей Протько]

phpus: если он новичек, то что бы он не выбрал - загубит проект. А CQRS даже в неумелых руках (я не представляю как можно криво реализовать этот довольно четко описанный паттерн, в отличии скажем от MVC) хорошо поддается изменениям и рефакторингу.

[Kokaas]

CQRS или SAO выбрать ?
И если пусши реализовать в одном приложении, на чем это скажется ?
Про SAO вообще не чего нету, CQRS хоть что-то, а про mvc где угодно можно найти..

[Сергей Протько]

Kokaas:
1) не SAO а SOA, Service Oriented Architecture. Грубо говоря соль в том что бы одно большое приложение разделить на кучу маленьких, которые общаются между собой. Скажем в контексте интернет магазина, админка одно приложение, сервер авторизации пользователей - другое, каталог - третье ну и т.д. Эта штука спасает на реально больших проектах.

2) CQRS - основная соль разделение ответственности на запись и чтение. Это позволяет полностью разделить логику работы с данными на модель для записи и для чтения, упростить логику хранения данных и логику работы приложения в целом. Если к этому добавить Event Sourcing то мы бонусом получаем еще и полную историю изменений (скажем правки цен для продуктов) в виде логирования действий пользователя. Это как минимум полезно для админки. Ну и да, CORS это архитектурный шаблон в пределах одного приложения, оно прекрасно сочитается с SOA.

3) MVC это UI паттерн и на бэкэнде популярен он благодаря такой штуке как RoR, которая популяризировала эту концепцию. В итоге миллионы хомячков орут на право на лево про MVC не понимая что это такое и почему это круто. А если есть понимание зачем это нужно и почему именно так а не иначе, становится проще ориентироваться во всех этих MVC/MVVM/MVP/HMVC/etc. Если вы не знаете принципов SOLID или там банально принципов ООП, то загоняться по таким вещам как разделение логики представления от логики приложения за счет введения дополнительного слоя вам еще рано осознавать. Хотя на практике применять можно. На бэкэнде это все намного проще в плане организации.

[Сергей Протько]

«Пользователь удалён»: где именно SOA + CQRS - не скажу. Да я даже не могу подсказать ни одного open-source проекта где CQRS используется полноценно, обычно эти вещи используют в дорогих и больших проектах, которые никто и никогда не будет выкидывать на гитхаб. Есть что-то типа проектов для обучения, например https://github.com/qandidate-labs/broadway но опять же это только пример применения концепции.

[Сергей Протько]

«Пользователь удалён»: почему же? PHP лучше ноды подходит для подобного. Как раз в силу схожести объектной модели с Java/C#.

Что до "не для мелкого бизнеса" - не факт. Скажем если мы пишем на PHP и используем Symfony2, то нам доступны готовые решения для организации проекта с использованием CQRS, нормальных доменных моделей, тестов и т.д.

В целом я согласен, что CQRS не для новичков. Но это довольно универсальная архитектура. Она по сути не подходит только в условиях многопоточных приложений с высокой конкурентностью ну и в случаях когда команда должна быть совмещена с запросом (например аналог array_pop через CQRS сделать не выйдет).

А причины по котором в опенсурсе этого нет те же, по которым там нет ничего толкового для собственного развития в плане DDD и т.д. Уровень разработок обычно ниже.

[Kokaas]

Значит особого смысла по этому поводу заморачиваться не стоит?
Крупный проект, это что ?)

[Сергей Протько]

Kokaas: крупный проект - понятие относительно. Для меня все что больше 10К человекочасов я уже воспринимаю как что-то большое. А есть проекты на сотни тысяч, миллионы человекочасов

[Kokaas]

Если писать нормальный магазин, то какой язык выбрать ?

[Сергей Протько]

«Пользователь удалён»: воу воу, вы давно с PHP работали? Если брать PHP 5.6 то он достаточно быстр что бы писать на нем что-то сложное. Он не медленне Python и уж явно быстрее Ruby. А на всякие там PyPy/jRuby (которая к слову никогда не будет поспевать за канонической реализацией) есть HHVM да и PHP7 на подходе, который будет уже раза в два быстрее 5.6.

Что до сишных модулей для пыха - да без проблем. Можно на си писать, можно на зефире, можно на Rust. Но как по мне это 0.1% случаев, когда нужно делать что-то в виде расширения. В остальных случаях - архитектурные решения и только. Скажем взять узкое место приложения и переписать его на go - это тоже архитектурное решение.

А если со старта проекта целиться на удиторию в n миллионов в день (прочитайте описание вопроса, там нет такого и близко) и тратить кучу времени на микрооптимизации, нанимать спецов за дофига денег, то шанс про*бать полимеры увеличивается с каждым днем.

Нужно как-то себя ограничивать в стремлении программировать ради программирования, и лучше побыстрее предоставить клиенту MVP. А там уже плясать дальше.

Kokaas: тот который вы знаете или под который можно спокойно найти разработчиков. Я бы сказал любой подойдет, но так как я php-шник то сами понимаете на какой язык я буду намекать. Единственное что скажу - какой бы язык не взяли, не пишите с нуля. Возьмите хотя бы фреймворки или отдельные компоненты.

[Сергей Протько]

«Пользователь удалён»: ну когда такие задачи ставятся - то да, но это не покрывает и одного процента задач) Это специфика работы. Если производительность - критична как фича проекта, то что поделать...

Answer 2

[FanatPHP]

Вечная тема.

Дело в том, что я не фотограф и становиться им не собираюсь, но я программист и сисадмин и мне надо устроить выставку своих фотографий.
Подскажите алгоритм моих действий:
1. Я должен купить рамочки и гвоздики для развески фотографий.
2. Также я должен достать какой-то фотоаппарат, который позволяет делать красивые фотографии. Как называется такой фотоаппарат или его аналоги? Сложно ли им овладеть?
3. Я должен щелкать вышеозначенным фотоаппаратом пока не нащелкаю достаточно для выставки.
Всё ли правильно?
update. приобрел аппарат Олимпус за 200 рублей. Тема исчерпана...

Миллион вопросов, и ни одного по теме. Чувак искренне верит, что знание множества страшных слов хоть чем-то ему поможет.

Comments

[Kokaas]

Нет, я знаю php с ооп знаком. Если сложно помочь, не отвечайте.

[FanatPHP]

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

[Сергей Протько]

Kokaas: советую вам почитать чего про паттерны проектирования и меньше зацикливаться на данном этапе понимния ООП на всяких там MVC. Уясните откуда взялась необходимость MVC (разделение на слои и введение дополнительного слоя для уменьшения связанности двух других), а как это назвать уже дело третье. В бэкэнде вообще православного MVC нет, есть только адаптации.

[Сергей Протько]

Kokaas: https://github.com/phptodayorg/php-must-watch

[Сергей Протько]

FanatPHP: ты же вкурсе что это бесполезно. Не парься, они рано или поздно умрут.

[Kokaas]

Если писать нормальный магазин, то какой язык выбрать ?

Answer 3

[xmoonlight]

Шпаргалка по шаблонам проектирования
Паттерны для новичков: MVC vs MVP vs MVVM

Comments

[phpus]

Это прошлый век =)
А шаблоны проектирования, то что надо!

[xmoonlight]

phpus: не знающим нужно ознакомиться со всеми типами, чтобы иметь полное представление и дальше - уже решать.

[phpus]

xmoonlight: Ну главное что бы его понесло куда надо, а то будет как я.. с начала на 1м напишет, потом на 2м.. и все равно не то.

Паттерны hmvc и mvc проще, чем новые.
А раньше был вариант только с include :D Такая блочная махина получалась, после mvc появилась и тут понеслось

[Kokaas]

Я знаком с MVC, MVP, MVVM. Вот думаю что есть что-то еще..

[Сергей Протько]

Kokaas: на бэкэнде это все не столь важно, особенно в контексте "умирающего PHP". Поскольку ваше приложение живет, грубо говоря, в пределах одного запроса, все это MVC сводится к следующему:

- формируем объект агрегирующий данные по запросу (можно вооружиться Symfony/HttpKernel)
- решаем что от нас хотят по этому запросу, то бишь ресолвим контроллер
- контроллер передает просьбу что-то сделать сервисному слою, сконвертировав данные из формата запроса в тот формат, который ест наше приложение
- сервисный слой делает логику и возвращает какой-то результат.
- контроллер собирает то что нам надо для ответа и формирует ответ... ну и отправляет это дело. То есть передает данные во View layer, а там уже что происходит совсем не важно. Мы там можем шаблончики рендерить, или JSON сериализацию делать...

Скажем HMVC в этом контексте просто позволяет из view layer формировать эдакие под-запросы. То есть так же формируется объект с данными по запросу, так же дергается фронт контроллер, ресолвится действие и формируется ответ, который затем выводится на страницу в нужном месте.

[Сергей Протько]

phpus: что значит "новые"? Ну да, MVC сформулировали раньше чем многие шаблоны (конец 70-х), но и всем этим "новым" паттернам уже лет 20. Большая часть принципов SOLID была сформулирована еще в конце 80-х. Новые.

То что вы пытаетесь использовать шаблоны проектирования при отсутствии всякого понимания "зачем это нужно" это лично ваша проблема. Есть принципы ООП, есть GRSAP, который пытается с колокольни SOLID объяснить откуда взялись шаблоны проектирования и почему именно так а не иначе... И самое грустное, что вот эти основы в принципе можно поднять с нуля за пару тройку месяцев. Но люди могут годами писать говнокод и не париться.

[Сергей Протько]

phpus: давайте маленький тест. Зачем нужен ООП? Ради чего все это?

[xmoonlight]

Сергей Протько: а ответить можно?)

[Сергей Протько]

xmoonlight: да конечно)

[xmoonlight]

Сергей Протько: ООП: однократное кодирование повторяющейся логики через "деревья" наследования с минимальными усилиями для любых манипуляций над объектами через выше стоящие контейнеры, их свойства или свойства конечных объектов.

[Сергей Протько]

xmoonlight: ну идея вроде бы и верна... но меня сильно смущает "дерево наследования". По идее можно и без наследования обойтись. Наследование позволяет лишь сократить объем дублирования кода. А в контексте PHP наследование только для этого и нужно, полиморфизма ж полноценного нет.

В целом же, у Боба Мартина хорошая трактовка была в каком-то из выступлений. Мол помимо объектов и обмена сообщениями между ними, у ООП самая большая сила заключается как раз таки в последних двух буквах SOLID.

[Kokaas]

Если писать нормальный магазин, то какой язык выбрать ?

[xmoonlight]

Kokaas: любой, проще - PHP.