Начало работы с Доменным Управляемым Дизайном на сайте электронной коммерции
бывший нелегко, выясняя, как смоделировать ожидаемое поведение продукта.
В основном материально-техническими ресурсами клиента управляют вдоль продуктов и skus.
Продукт имеет много skus, но единственный sku составляет несколько атрибутов продукта.
Позвольте мне дать пример.
Скажем, я продаю Вам рубашку. "Рубашка" является продуктом с некоторым идентификатором продукта. Если это входит маленькое, среднее, большое, то каждый из тех размеров был бы связан с sku #.
достаточно легкий до сих пор, но если рубашка также будет существовать нескольких цветов, скажем, красных, желтых, и зеленых, то будет девять skus (красные/маленькие, красные/средние, красные/большие, желтые/маленькие, и так далее).
Добавьте к этому проблему, что типы атрибутов могут отличаться для различных продуктов. Рубашка могла бы иметь размеры и цвета, сумочка могла бы иметь различные стили дескриптора или шаблоны, и я не буду знать заранее, это вещи, которые клиент должен смочь ввести специальным способом.
Какие-либо идеи о том, как приблизиться к этому с точки зрения DDD? Я "ve выпекание моей лапши на нем в течение нескольких дней теперь.
Спасибо.
2 ответа
Прежде всего, вы должны рассматривать каждый артикул как отдельный атрибут продукта, а не объединять их. Если товар может иметь цвет и размер, это два различных атрибута, а не один (например, красный / маленький, красный / средний и т. Д.). Предположим, у продукта есть пять атрибутов, каждый из которых имеет 4 возможных значения. Тогда у вас будет 4 ^ 5 = 1024 skus. Это быстро превращается в кошмар обслуживания.
Итак, первыми двумя объектами в вашей модели предметной области должны быть ProductDefinition и Атрибут . Причина, по которой я выбираю ProductDefinition в качестве имени, а не Product , заключается в том, что это просто ярлык для некоторого типа продукта, например рубашки. Это еще не маленькая желтая рубашка.
Атрибуты могут иметь возможные значения, поэтому это создает третий объект домена: AttributeValue . Связь между Атрибутом и 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
Мы сделали подобную систему...
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
Единственное, что я бы изменил в нашей системе - я бы использовал базу данных документов для хранения всего, но в нашем случае граф на самом деле был намного глубже, каждый уровень имел свои собственные поля.