1. Архитектура программного обеспечения

Фреймворк DjangoSHOP, как следует из названия, это фреймворк, а не программное обеспечение, которое работает из коробки. Сайт электронной торговли, построенный на базе DjangoSHOP, состоит из фреймворка, большого количества других Django приложений и собственной реализации торговли. DjangoSHOP может показаться сложнее, чем готовое решение, но зато он даёт огромные преимущества программситу в процессе реализации интернет-магазина.

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

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

Вместо того чтобы искать программное обеспечение, которое может обрабатывать такие сложные требование, нужно лишь написать собственные плагины, способные справиться с этим. С Django, REST и djangoSHOP фреймворков это обычно реализуется в несколько десятков строк Python кода. А теперь сравним решения, которые могут обработать такие сложные требования. Как правило, они содержат огромное количество функций, нужные малому количеству продавцов, но раздувающие общую сложность системы, что делает такое программное обеспечение дорогими в обслуживании.

1.1. Дизайнерские решения

1.1.1. Единый источник - есть истина

Один из основополагающих аспектов хорошего дизайна программного обеспечения должен следовать принципу "Не повторяйся", которое часто обозначается DRY (Don’t repeat yourself). В djangoSHOP мы стремимся к одному источнику информации, где это возможно.

Например, посмотрите на shop.models.address.BaseShippingAddress. Всякий раз, когда мы добавим, изменить или удалить поле, Django ORM будет получать уведомление и команды ./manage.py makemigrations с последующим ./manage.py будут обновлять нашу схему базы данных. Но даже поля ввода нашей адресной формы должны принять все изменения в нашей модели адреса. Даже проверка поля формы на стороне клиента принимает изменения в нашей модели адреса. Как мы видим, здесь наш единственный источник информации - адрес модели.

1.1.2. Полнота функциональности

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

В противном случае этот фреймворк содержит ошибку, а не только недостающие функции! Я уверен, что некоторые торговцы придумали очень странные идеи, о которых я никогда не думал. Если фреймворк djangoSHOP мешает добавить функцию, то не стесняйтесь и создайте отчет об ошибке. Требование "Полнота функциональности" для фреймворков является аналогом термина "Полнота Тьюринга" для языков программирования.

Имейте в виду, что на многих сайтах требования интернет-магазина пропатчены в существующий код. Это означает, что каждый раз, когда выходит новая версия программного обеспечения для эл. торговли, патч должен быть повторно принят. Это может стать весьма опасным, когда дыры безопасности в этом программном обеспечении должны быть немедленно закрыты. Вместо этого в DjangoSHOP разработано так, что внедрение сторонних плагинов происходит засчёт наследования определённых классов и переопределения соответствующих шаблонов.

1.1.3. Минимализм

В двух словах, djangoSHOP предлагает набор базовых функциональных возможностей, чтобы быть "простым и глупый" (KISS - keep simple and stupid) без необходимости изобретать колесо:

• Каталог для отображения списка товаров и представления карточки товара.

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

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

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

1.1.4. Модульное разделение дела

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

Имея многомодульную систему, программисты получают ряд преимуществ:

• Нам не надо изобретать колесо для каждой требуемой функции.

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

• Нет опасности создать циклические зависимостеи, как и обычно происходит в больших библиотеках и автономных приложениях.

• Новичкам легче понять, какая часть системы отвечает за что.
• Легче заменить один компонент на другой.

К счастью, Django дает нам все инструменты для объединения зависимостей вместе. Если, например, мы хотели бы использовать одну из многих PHP-платформ для создания интернет-магазина, мы должны были бы остаться внутри своей скромной коллекции для приложений сторонних производителей, или изобретать колесо. Это часто является ограничивающим фактором по сравнению с огромной экосистемой Django.

1.1.5. Контроль логики магазина за вами

Там где это возможно, djangoSHOP пытается делегировать ответственность в принятии решения на самого продавца. Возьмем небольшой пример для понимания: когда покупатель добавляет товар в корзину, djangoSHOP обращается к реализации модели товара, чтобы понять данный товар уже есть корзине или нет. Если товар есть в корзине, то нужно только увеличить его количество. Это позволяет реализовать гибкую систему вариантов товара.

1.2. Ядро системы

В основном, систему интернет-магазина можно разделить на три фазы:

1.2.1. Фаза покупки

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

1.2.2. Фаза оформления заказа

Здесь покупатель должен иметь возможность изменить количество товара или убрать товар из корзины.

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

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

1.2.3. Заключительная фаза

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

1.3. Плагины

В DjangoSHOP определены 5 типов плагинов:

• Product models (Модели товара)
• Cart modifiers (Модификаторы корзины)
• Payment backends (Бэкенд оплаты)
• Shipping backends (Бэкенд доставки)
• Order workflow modules (Модуль рабочих процессов заказа)

Они могут быть добавлены как сторонние приложения djangoSHOP или интегрированы в реализацию продавца.