Customizing, extending Django-oscar to meet customer requirements

Приветствую,

собственно сабж. Интересует аргументированная оценка бюджета и сроков создания интернет-магазина на сабже. Соответственно дизайн и верстка пока одного сайта (сабж., см. ниже, с функционалом multistore).

Из основных требований заказчика:

- multistore/multivendor;
     django.contrib.sites <=> oscar.apps.partner, ....sites <==> oscar.apps.XXX

     по мотивам:     http://devdocs.magento.com/guides/v2.0/config-guide/multi-site/ms_over.html     

     по подобию:    http://docs.sylius.org/en/latest/book/channels.html     

                              http://docs.drupalcommerce.org/v2/store.html     

    на примере реализации чего-то такого на Оскаре (у заказчика в этом плане немного отличный юзекейс) :                               https://github.com/edx/ecommerce/blob/master/ecommerce/core/models.py#L27-L33

- мультивалютность, мультиязычность и локализация(формат вывода чисел, дат, денег и тд);            

     валюта:      

     oscar.apps.partner.models.StockRecord  

      """Strategy class, decouple products from stockrecords and provides a swappable ‘strategy’ component for       selecting the                     appropriate stockrecord, calculating prices and availability information       (приложение  Partner). Supports multiple                           stockrecords per product which can be in different currencies.   

    """      

    языки:   

    django-parler   django-modeltranslations   django-hvad   

    Аргументированно выбрать соответствующую "батарейку" (производительность, масштабируемость...и тд).  

    Есть соответствующая тема в профильной группе, вопрос оставлен открытым.    

    Необходима экспертная оценка.

      локализация:      

     django-oscar по всей видимости определяет форматы(локаль) по выбранному языку, что представляется не полным и не              совсем точным.  

     GeoIP, HTTP_ACCEPT_LANGUAGE, User preferences, etc . 

     Необходимо экспертное заключение.

    Переключение единиц измерения (метрическая<==>имперская). Можно во фронтенде но, обязательно пытаемся сначала             определить ед.изм., обязательно  предоставляем выбор, запоминаем выбранное и тд. по аналогии с языками и валютами.

- универсальный модуль доставки:

            способы доставки добавляются в админке, напр- 

•  Укрпочта - тарифная сетка кг/зона, сроки доставки зона/время и тд, доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по весу, сумме вложения(заказа) и тд
•  НоваяПочта - тарифная сетка кг/зона, сроки доставки зона/время и тд, доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по  весу, сумме вложения(заказа) и тд
•  ХХХ - тарифная сетка кг/зона, сроки доставки зона/время и тд, доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по весу,  сумме вложения(заказа) и тд
•   ....
• Самовывоз, доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по весу,  сумме вложения(заказа) и тд

- Онлайн оплата:

•        LiqPay (Card, P2P), доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по сумме оплаты(заказа) и тд
•        2CheckOut (Card, paypal), доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по сумме оплаты(заказа) и тд

- Оффлайн оплата:

•        Генерация счета (версия для печати, pdf) с реквизитами для валюты В1, доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по сумме  оплаты(заказа) и тд
•        .....
•        Генерация счета (версия для печати, pdf) с реквизитами для валюты Вn, доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по сумме оплаты(заказа) и тд
•        Оплата наличными, доступность для Зон, групп Партнеров, групп Клиентов, групп Товаров, ограничения по сумме оплаты(заказа) и тд

- Расширение Оскара приложениями Refund (возврат товара), Exchange (замена товара, частично повторно использует Refund и Order), Fulfill( заказ на производство или на закупку)

-Учет остатков материалов.

     Помимо обычного учета остатков товара для некоторых товаров необходим учет комплектующих их товаров. Напр., товар "А"     собирается из товара "В" и трех единиц(размерности могут быть любыми,- шт., м2, м.п и тп) товара "С". Для определения               доступности к заказу товара "А" необходимо проследить есть ли необходимое кол-во "В" и "С"

- Workflows (checkout, payment, fulfilment, order, etc) framework:

  django-oscar безусловно представляет инструменты и широкие возможности по кастомизации процессов (workflows) электронной коммерции,- pre-condition and skip-condition method в приложении Checkout,  oscar.apps.order.processing.EventHandler, Order pipeline, эвенты, сигналы и тд. Но этот набор разнотипных инструментов представляется весьма сложным и запутанным для, допустим , штатного программиста заказчика, чья задача будет вносить те или иные изменения в соответствующие процессы.

  Выходом в данном случае представляется либо полноценная качественная документация (с примерами) для штатного программиста по возможностям Оскара по реализации или кастомизации  workflows.  Либо же, создание универсального механизма для реализации и кастомизации workflows, по типу, как:

  в django-shop

  WorkflowMixinMetaclass, -add configured Workflow mixin classes to OrderModel and OrderPayment to customize all kinds of state   transitions in a pluggable manner, - своего     рода менеджер воркфловов. WorkflowMixinMetaclass от части можно использовать по типу концепции OrderType заложенной в Commerce 2.x (drupal8). Где OrderItem,     или их набор,  определяют (OrderTypeResolver) тип Заказа (OrderType), а через него определяют соответствующие специфические workflows(workflow groups: checkout,   payment, fulfilment, order, etc ).

  to define rules in a programmatic way, https://django-shop.readthedocs.io/en/latest/reference/order.html#order-workflows

  в sylius

  http://docs.sylius.org/en/latest/book/state_machine.html

  http://docs.sylius.org/en/latest/book/orders.html#the-order-state-machine

  http://docs.sylius.org/en/latest/book/payments.html#payment-state-machine

  http://docs.sylius.org/en/latest/book/shipments.html#the-shipment-state-machine

  http://docs.sylius.org/en/latest/book/checkout.html#checkout-state-machine

 в commerce2.x

 https://github.com/drupalcommerce/commerce-docs/blob/master/v2/orders/order-types.md

 https://drupalcommerce.org/blog/43169/commerce-2x-stories-workflows

 Здесь необходима экспертная оценка.

- Производительность/Асинхронное исполнение заданий;

       Оффлоад всего чего только можно в Celery c целью уникнути блокировок вью.

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

- Производительность/Повторное использование поисковых индексов;

        django-oscar использует поисковые движки (Солр, Эластик) для поиска по товарам, фасетного поиска. 

        Т.е. категории, товары уже проидексированы.

        Представляется логичным использование уже готовых поисковых индексов, например, для вывода товаров категории или           вывода вариантов товара (вместо  queryset в медленную БД, searchqueryset в Поисковый движок).

        Аналогично,  django-oscar для фильтрации(фасетной) по товарам/категориям использует фасетный поиск поисковиков.

        Представляется логичным использовать его же и с целью сортировки на страницах со списком товаров (стр. категории и тп)         Здесь необходима экспертная оценка.

        "beds" через навигацию -->> https://www.wayfair.com/Beds-C46122.html

        "beds" через поиск -->> https://www.wayfair.com/Beds-C46122.html?rtype=9&redir=beds

        "beds" через поиск с уточнениями -->> https://www.wayfair.com/filters/Beds-l12-c46122-O115~King-P116~0~250.html?rtype=9&redir=beds+king+under+%24250

-Тесты;

        BDD, TDD. FT. CI.

-Документация;

         В виде комментов в коде, само собой разумеющееся (PEP-8.Comments).

         В виде комментов к PR (pull requests), само собой разумеющееся.

         В виде записей и комментариев ведущихся с помощью Issue-инструментов репозиториев (Битбаклет, Гитхаб). Тоже вроде бы вопрос культуры и стиля  программирования.

         В виде описаний, схем и инструкций ведущихся с помощью Wiki-инструментов репозиториев (Битбаклет, Гитхаб).

         Ну и основная тех.док в "Read the Docs". Что?Как?Зачем?Кастомизируем в Оскаре. Что?Как?Чем?Расширяем Оскар. и тд.  и тп.

         Цель тех.документации:

         а) возможность, при необходимости, сторонним разработчикам быстро вникнуть в проект или любую его часть для продолжения работы над проектом

         б) в случае наличия у заказчика штатного разработчика позволить ему быстро сориентироваться в проекте в целом и в тех его частях которые  связаны с бизнесом непосредственно,- для реализации скидок и акций (oscar.apps.offer, oscar.apps.promotions), работы с купонами (oscar.apps.voucher), сбора статистики (oscar.apps.analytics), кастомизаци продуктов(ProductType) и цепочек действий (workflows: checkout, payment, fulfillment, order etc)   

-Дизайн запоминающийся, выдающийся, в соответствии с лучшими практиками UX/IX;

P/S:

Помимо python/django/django-oscar/PostgreSQL возможно рассмотреть варианты:

1) php/symfony/sylius/PostgreSQL

2) python/django/django-shop/PostgreSQL или php/drupal8/Commerce2x/PostgreSQL