Начало работы с Domain Driven Design на сайте электронной коммерции - PullRequest
4 голосов
/ 04 июля 2010

трудно понять, как моделировать ожидаемое поведение продукта.

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

У продукта есть много skus, но один sku учитывает несколько атрибутов продукта.

Позвольте мне привести пример.

Допустим, я продаю тебе рубашку. «Рубашка» - это товар с некоторым идентификатором товара. Если это маленькое, среднее, большое, то каждый из этих размеров будет связан с sku #.

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

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

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

Спасибо.

Ответы [ 2 ]

2 голосов
/ 04 июля 2010

Прежде всего, вы должны рассматривать каждое изделие как отдельный атрибут продукта, а не объединять их.Если продукт может иметь цвет и размер, это два разных атрибута, а не один (например, красный / маленький, красный / средний и т. Д.).Предположим, что продукт имеет пять атрибутов, каждый из которых имеет 4 возможных значения.Тогда у вас будет 4^5=1024 skus.Это быстро становится кошмаром обслуживания.

Итак, первые два объекта в вашей доменной модели должны быть ProductDefinition и Attribute.Причина, по которой я выбираю ProductDefinition в качестве названия, а не Product, заключается в том, что это просто ярлык для какого-либо типа продукта, например, рубашки.Это еще не маленькая желтая рубашка.

Атрибуты могут иметь возможные значения, поэтому это относится к третьему объекту домена: AttributeValue.Соотношение между Attribute и AttributeValue равно 1: n.Атрибут имеет несколько значений, значение принадлежит только одному атрибуту.

Обратите внимание, что AttributeValue содержит все возможные значения для атрибута, а не фактическое значение для одного продукта.Это фактическое значение становится отношением между ProductDefinition, Attribute и AttributeValue: ProductAttributeValue.Пример использования рубашки в модели базы данных:

ProductDefinition   Attribute       AttributeValue
1 | Shirt           1 | Color       1 | 1 | Red
                    2 | Size        2 | 1 | Yellow
                                    3 | 1 | Green
                                    4 | 2 | Small
                                    5 | 2 | Medium
                                    6 | 2 | Large

Теперь мы смоделировали одно определение продукта, два атрибута и три значения атрибута для каждого атрибута.Предположим, мы хотим смоделировать три рубашки: маленькую красную, маленькую зеленую и большую желтую.Это приводит к следующему содержанию ProductAttributeValue (ProductId, ProductDefinitionId, AttributeId, AttributeValueId):

ProductAttributeValue
1 | 1 | 1 | 1
1 | 1 | 2 | 4
2 | 1 | 1 | 3
2 | 1 | 2 | 4
3 | 1 | 1 | 2
3 | 1 | 2 | 2
0 голосов
/ 06 июля 2010

Мы сделали такую ​​систему ..

ProductDefinition
  has Type (Shirt, Handbag)
  has many ProductFieldDefinition

ProductFieldDefinition
  has Type (Color, size, pattern)

Product
  has ProductDefinition
  has SKU
  has many ProductField
      has ProductFieldDefinition
      has Value

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

...