лучший способ смоделировать следующий сценарий - PullRequest
2 голосов
/ 17 октября 2011

Я начинаю в мире DD и пытаюсь создать достаточно простое приложение.У меня есть несколько вопросов о том, как я выбираю модель своего домена.

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

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

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

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

Правильно ли я моделировать эти карты как две отдельные сущности (CatalogueCard и OrderCard), даже если они имеют одинаковый набор свойств?

Тот же вопрос может быть задан также для адреса, к которому должна быть адресована карточка (у каждой позиции заказа будет адрес), и для адреса выставления счета.Должны ли они быть смоделированы как полностью отдельные сущности?

Заранее спасибо

1 Ответ

1 голос
/ 17 октября 2011

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

...