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

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

Как вы это будете делать - дело третье.

Какую архитектуру(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 не в счет).

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

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

На Tumblr? никак.

Вам нужен движек интернет магазина, либо же разработка оного под заказ.

Обычно за такое берутся студенты (1-2 курс)

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

Я лично заказал бы только под мои требования CMS (а точнее в моем случае потратил бы пару недель и написал бы сам).

Но если выбирать между этими двумя… пройдемся по пунктам:

1) Тут выигрывает x-cart (хотя опять же смотря в какой редакции, но даже в самое дешевой — выигрывает, хоть и не сильно)
2) Тут уже сложнее, насколько я помню из коробки этого нету. Да и для x-cart вроде бы тоже не видел, а для магенту есть точно. Но быть может моя информация устарела. Я x-cart ресерчил где-то пол года назад.
3) Из коробки в дорогих редакциях x-cart или же модули для магенту. Но если брать модули то возможностей больше.
4) тут сказать ничего не могу.
5) есть вроде бы в обеих. Явного лидера назвать не могу
6) Модули
7) X-CART примитивнее, но с другой стороны с разработчиками под magento намного более приятная ситуация. Да и сама структура непривычна только первое время.
8) ERP — интеграции есть. Для x-cart знаю что некоторые конторки предоставляют возможность интеграции в обе стороны для множества ERP систем. Но точно ничего сказать не могу ибо с этим никогда не сталкивался. Мод магенту же с этим проще. Есть как бесплатные так и платные решения.
9) если судить объективно — и то и то выглядит ущербно. Из коробки покрайнемере. По поводу костомизации в этом вопросе ничего сказать не могу, ибо не занимался. Хотя с другой стороны ничего лучше особо и нету… и это печально
10) тут обе системы вроде подходят
11) нифига админы не в грязных свиторах… Ну да несуть. По поводу x-cart честно не знаю в этом плане, но допилить какие-то механизмы для более шустрого поиска можно. Так же как и для магенту использовать для поиска сфинкс/монго. При небольшой заточке напильником, исходя из возможностей вашего сервера, нагрузки они оба будут выдерживать примерно одинаково.
12) Тут однозначно лидер магенту. Потому то он и стал так быстро набирать обороты в самом начале.

Такие дела.

Типа такого?

Я не специалист, но если руководствоваться здравым смыслом, то ниша сильно влияет. Ноутбуки востребованы, но конкуренция на рынке слишком большая. Вам придется изрядно постараться что бы привлечь покупателей. Обычно это какие-то акции, более качественный сервис за ту же сумму и т.д. С другой стороны если выбрать более специализированную нишу, количество клиентов будет сильно ограниченным. Но если конкуренция не большая, шанс на большую прибыль выше.

раздели систему на компоненты, исходя из задачи. Скажем, если исходить из паттрена MVC — должны быть объекты для работы с базой (Order, Client и т.д.), класс занимающийся репрезентативной частью и контроллеры (OrderController (Причем для пользовательской части можно наследовать от Controller а для админки AdminController), ClientController, CatalogController). Магазин можно грубо разделить как минимум на каталог и корзину. Есть еще доставка, оплата и т.д. Все эти части можно разнести по модулям (в случае доставки и оплаты — это будут контроллеры и модели)…

Ну это так, примерно. Просто надо разбить все на эти самые подзадачи. Причем надо продумать как так разбить что бы изменения в одном компоненте не привели к необходимости менять что-то еще…

www.turbosquid.com/ — сервис продажи 3D моделей. Чем такой вариант не подходит?

А так всегда есть ucoz, там вроде бы есть возможность создать интернет магазин.