Зачем представлять корзины покупок и заказывать счета по-разному в доменной модели?

Question

В прошлом я создавал некоторые системы корзины покупок, но я всегда проектировал их так, чтобы конечный счет-фактура заказа был просто корзиной покупок, которая была помечена как «купленная».Вся логика добавления / удаления / изменения товаров в корзине также является логикой заказа.Все данные хранятся в тех же таблицах в базе данных.Но, похоже, это неправильный способ разработки сайта электронной коммерции. Может ли кто-нибудь объяснить преимущества отделения корзины покупок от счетов в модели домена?

Мне кажется, это привело бы к большому дублированию кода, дополнительному набору таблиц в базе данных и усложнило бы его поддержку в случае, если система должна начать принимать более сложные заказы (например, указаниевыбранные параметры для элемента, который может изменить или не изменить цену / доступность / время доставки заказа).Я предполагаю, что просто не видел свет, поскольку каждая книга и другой пример, который я вижу, похоже, разделяют эти две, на первый взгляд, похожие проблемы - но я не могу найти никакого объяснения относительно пользы от этого!Кроме того, в системах, которые я проектирую, изменения часто сделаны после , когда первоначальный заказ подтвержден.Нередко предметы удаляются, заменяются или добавляются впоследствии (но до их выполнения).

Answer 1

В вашем сценарии, я не думаю, что вы хотите изменить запись, а применить к ней изменения. Таким образом, у вас будут записи, указывающие на изменение цены. Например, если цена на ключ была изменена с 10 до 15 долларов, вам нужно будет добавить запись, указывающую изменение цены на + 5 долларов.

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

Скажем, вы опубликовали виджет B за 25 долларов с описанием, в котором говорится, что у него Z-ключ. Позже вы узнаете от производителя, что у него есть X-Dongle, а не Z-Dongle, и в результате вам нужно снизить цену. Между тем, как вы опубликовали и исправили ошибку, кто-то покупал указанный виджет за 25 долларов.

Затем этот клиент звонит после обнаружения отсутствия Z-Dongle и хочет вернуться и получить полный возврат средств. За исключением того, что теперь у вас есть их запись, показывающая, что они купили продукт с X-Dongle за 15 долларов меньше, чем они первоначально заплатили. Представитель отдела обслуживания клиентов говорит ему, что в описании CLEARLY говорится, что у него есть X-Dongle - что теперь?

Answer 2

Я как раз собирался утверждать, что различие было бы хорошо, по крайней мере, сохранить его, чтобы счет не изменялся, только чтобы прочитать ваше замечание о том, что на самом деле в вашем случае счета имеют тенденцию изменяться? Я бы сказал, что на этом этапе они все еще напоминают «заказ», а не фактуру. Одной из причин, по которой они могут быть разделены, может быть то, что в вашей корзине покупок есть ссылки на товары, которые могут быть изменены, в то время как вы не хотите, чтобы в ваших счетах указывались товары, которые могут измениться (что приводит к описанию другого товара при рассмотрении счет-фактура по сравнению с датой / временем создания счета-фактуры).

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

Answer 3

Учитывая производительность и коэффициент конверсии заказа:

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

2. высокий уровень параллелизма и низкий коэффициент конверсии ухудшат ситуацию.

Answer 4

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

Заказ представляет информацию о заказе ... способ оплаты, информацию о транзакции и т. Д. Это всего лишь представление о том, "какова вся информация о том, как я купил корзину". Это вся информация, которую вы предоставляете, когда вы идете в регистр и платите.

Я считаю, что это простой способ решить, что и куда идет, и дает хорошую модель того, какой может быть реальная корреляция.