CRUD-модель для управления каталогом товаров

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

Теперь я хочу показать способ ее применения на примере управления каталогом товаров Интернет-магазина: как она влияет на ход мыслей и помогает генерировать вопросы для проверки полноты требований.

Погружение в контекст

Планируется создать Интернет-магазин с двумя приложениями:

Административное для продавца: изменять сведения о товарах и их остатка, обрабатывать заказы, следить за денежными потоками, вести скидки и акции и прочее.
Интернет-магазин для покупателя: просматривать каталог товаров, делать заказы, следить за их выполнением.

Одна из главных возможностей продавца — управление каталогом товаров.

Я открыла одну из популярных площадок онлайн-торговли OZON и нашла, для примера, товар "пазлы", чтобы посмотреть примерное описание сущности товара для хранения.

Код товара
Название товара
Основное фото товара — ссылка на изображение и/или отметка, что оно основное
Дополнительные фото товара
Бренд — ссылка на компанию
Количество элементов
Материал (специфичное для пазлов) — ссылка на запись в справочнике
Длина готового пазла (специфичное для пазлов)
Цена без скидки
Цена со скидкой
% скидки
Данные о рассрочке

Логически выделяю следующие группы свойств:

Базовые: доступные в списке товаров.
Цены: все о цене товара и скидках.
Основные: доступные как в списке, так и при просмотре товара.
Дополнительные: доступные только при необходимости получить детальные сведения о товаре. Могут не отображаться сразу, а только по запросу.

Есть свойства, которые ссылаются на справочники. Например: материалы, тематика. Их стоит рассматривать отдельно, т.к. значения в справочниках можно менять и удалять. В этой статье я не буду рассматривать сценарии изменения связанных справочников. Основной объект исследований: товар.

В процессе проектирования следует помнить, что доступ к товарам есть с двух сторон: и у продавца, и у покупателя.

Сценарии, в которых используют товар покупатели:

Просмотр каталога товаров.
Выбор товара и добавление в корзину.
Удаление товара из корзины.
Оформление заказа на основании корзины.
Оплата заказа и формирование чека со списком товаров.

Сценарии, в которых используют товар продавцы:

Управление каталогом товаров: создание, выставление на витрину, снятие с витрины, редактирование описания, настройка цен, удаление.
Организация скидок и акций на товары.
Просмотр заказов покупателей.
Контроль прибыли по всем товарам и для каждого товара отдельно.
Контроль оборота товаров: сколько купили и продали в выбранный период.
Закупка товаров у поставщиков.

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

CRUD-модель для Товара

Функциональность: управление каталогом товаров для продавца.

Есть влияние на все сценарии работы с товарами как для роли продавца, так и для роли покупателя.

Продавец может делать с товарами все что угодно — управление каталогом товаров же! Или нет? Возьмем CRUD-модель и прогоним сценарии по ней.

Далее по статье все вопросы, которые повлияют на проектирование БД и логику работы системы, будут выделены курсивом.

C - Create - Создавать

Один товар

Создать один товар — тут вроде бы ограничений нет, все хорошо.

Сценарии продавца

Покажем незаполненную карточку с описанием товара. Продавец ее заполнит. Проверим, что данные введены корректно и сохраним товар. После чего он появится в каталоге. И все?

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

Возникает дополнительный вопрос: надо ли давать возможность указать доступное количество для продажи сразу, при создании товара, или нет?
Думаю, что не стоит. Не надо смешивать возможность пополнять остатки и создавать записи в справочнике. Пользователь может увидеть товар сразу, но он будет недоступен для заказа, пока запасы в магазине не пополнят в другом сценарии.

Много товаров

Создавать несколько товаров за раз: насколько это нужно будет в нашей системе? Я бы отказалась для начала от такой возможности. Она может повлиять на удобство использования и продажи, но делать это не быстро.

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

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

Сценарии продавца

Для Интернет-магазина это может выглядеть как создание списка товаров, в котором вводятся только основные параметры и загружаются фотографии.

Сценарии покупателя

Для покупателя подобное тоже можно придумать. Главное понять, насколько это ценная возможность.

R - Read - Читать

Один товар

Получение всей информации о товаре из базы данных, которая у нас есть.

Сценарии продавца

Точки входа: откуда могут запросить подробную информацию о товаре?
Например: из каталога, из заказа, откуда еще?
Какой уровень вложенности данных должен быть при формировании объекта Товар на сервере?
Например, сразу ли отдавать ссылки на все фотографии в ответе или только основную, а дополнительные получать отдельным запросом?
Надо ли сразу показывать всю информацию о материале товара, или пусть, если хочет почитать про материал, нажимает на кнопку и запрашивает информацию о нем отдельно?
И подобные вопросы.

Сценарии покупателя

Точки входа, как у продавца.
Поскольку сведений о товаре много, то обязательно ли их всегда сразу полностью загружать на страницу, или можно частями?
Нужно решить сколько запросов информации о товаре мы будем делать. Возможно есть такая информация о пазле, которую хотят видеть 2 из 1000 пользователей. Можно такие сведения вынести в отдельный запрос к серверу "Запрос дополнительной информации о товаре", чтобы ускорить обработку.

Много товаров

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

Какие нужны фильтры?
Нужно ли уметь сортировать записи в списке?
По какому правилу по умолчанию сортировать записи в этом списке: название товара по алфавиту или как-то еще?
В каталоге может быть 1 млн товаров. Список надо будет отдавать постранично — нужна пагинация.
Какие данные о товаре будут использоваться при его добавлении в корзину? Стоит подумать о том, что "товар в списке" это отдельная структура данных. Их меньше чем в полном описании товара.

Вопросы к сценариям продавца и покупателя одинаковые.

U - Update - обновлять

Один товар

Казалось бы, все очень просто: зашел, отредактировал товар, сделал проверки, как при создании документа, сохранился. Повторил в голове список вопросов из Create. Но не все так просто.

Вопросы:

Есть ли параметры, которые нельзя менять после создания?
Например, код товара.
Как повлияют изменения на связанные документы, отчеты, справочники?
Если товар уже использовался в заказе покупателя, то как изменение названия или цены повлияют на этот заказ? Заказ менять нельзя — это факт продажи, исторические сведения.
Есть заказ с измененным товаром. Изменена цена. Захотели увеличить количество товара. По какой цене он должен быть добавлен: по новой или по старой? Или вообще надо делать новый заказ?
Нужно ли хранить историю изменений товара?
Например, историю изменения цен. Это логирование действий.
Как быть в случаях, когда товар заменили цену, а покупатель только что добавил его в корзину со старой ценой и оформляет заказ?
Можно ли отменять изменения?
Что будет с пользователями, которые только-только добавили товар в корзину с новой ценой, продолжают работать с заказом, и тут внезапно изменения отменили? Лучше, конечно, так не делать в Интернет-магазине. Это все усложнения логики, которые не нужны :)

Много товаров

Проработаем план действий на время обработки запроса:

Какие цены будут видеть пользователи в каталоге в процессе изменений?
Все цены обновятся сразу или будут обновляться плавно, по одной?
Что делать, если в процессе изменения данных для одного из товаров получена ошибка?
Отменять все изменения, пропускать ошибку? Выводить в отчете? Продолжать изменения дальше или остановить изменения?
Что, если товар добавлен в корзину покупателем, его цена изменилась в результате массового изменения цен, и тут в середине массового изменения произошла ошибка?

Сценарии покупателя

Смотрим на предыдущий опыт по массовому созданию товаров и на сценарии продавца. Придумываем вопросы :)

D - Delete - Удалять

А что сложного в том, чтобы просто взять и удалить товар из каталога? А сложности есть. Особенно, если он уже используется в каких-то документах. Как, например, все тот же Заказ покупателя.

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

Один товар

Сценарии продавца

При проектировании модели данных выбирают один из способов реализации:

Добавляют для объекта флаг “Видимость”. При создании устанавливают true. При удалении переводят в false. Это отметка о перемещении в корзину. Объект как бы удален, и как бы нет.
Физически удаляют товар из БД, если его еще нигде не использовали, ни в каких документах.
Физически удаляют товар из БД, если все необходимы сведения об объекте продублированы в связанных документах и нигде нет ссылок на запись в каталоге.
Удалять товар нельзя, но можно изменить статус. Например ”недоступен для покупки”. Или обнулить доступные остатки. Вопрос к заказчику: как ему нужно?

Сценарии покупателя

Но что же происходит у покупателя, когда товар удаляется? Такие вопросы могут быть:

Что если товар только что добавили в заказ, он еще не оплачен, и его хотят удалить?
Это решение принимает заказчик. Можно запрещать удалять товар в этот момент, или не давать завершить покупателю работу с заказом.
Как отображаются удаленные товары у покупателя в старых заказах, и в тех, которые находятся в ожидании доставки?

Много товаров

Все как для одного товара, но опять же стоит вспомнить, что массовые операции — долгий процесс.

Все товары удалятся сразу или по одному?
Что делать, если в процессе удаления данных для одного из товаров получена ошибка?
Что, если товар добавлен в корзину покупателя, а потом удален?

Итог

Это была первая статья с примером применения CRUD-модели в процессе проектирования. Я показала, как она помогает мне запустить мыслительный процесс и начать придумывать сценарии использования и проверять полноту требований.

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

Уже сейчас можно выделить общие вопросы, которые рекомендую исследовать в процессе проектирования систем:

Один объект:
1. Определение способа удаления: отметка об удалении или физическое удаление из БД
2. Доступность удаленных сведений для пользователей с другими ролями
3. Исторические сведения: влияние на связанные документы и отчеты в прошлом
4. Одновременное использование: влияние удаления на других пользователей, если они работают с этими данными

Про общее описание CRUD-модели

Екатерина Ананьева
Основатель IT-школы системного анализа и проектирования GetAnalyst
k@getanalyst.ru

Введение

Погружение в контекст

CRUD-модель для Товара