DDD - проблема модели домена

Question

У меня есть обсуждение с партнером, у нас есть этот сценарий:

**Publishers root entity 
Advertiser root entity**

Каждая из этих субъектов делится общей информацией:Электронная почта, BillingAddress, NormalAddress, Sex, SSN и т. Д.

Я принял решение: личность объекта с объектом значения и остальными свойствами. Таким образом, если я хочу получить доступ к конкретной информации о человеке (электронная почта, секс, dateofbird), мне не нужно просматривать издатель или корневые объекты, чтобы получить его (относиться к человеку как к совокупному корню).

Sample: **Person.BillingAddress.Address1 :
        Person.BillingAddress.Address2 :
        Person.BillingAddress.POBOX :
        Person.Email :
        Person.Sex**

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

Как лучше всего это сделать?. Если у вас есть один, пожалуйста, направляйте нас.

Спасибо, Педро де ла Круз

Answer 1

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

Answer 2

Вам следует благоприятный состав над наследством.

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

Answer 3

В этом случае меня не волнует наследство - я думаю, что это хрупко.

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

Answer 4

Я думаю, что рекламодатель и издатель должны унаследовать от компании, а компания должна иметь коллекцию контактов (или лиц в вашем случае).

Технически компания может иметь коллекцию филиалов.

Затем каждая филиала может иметь адрес, и каждый контакт (человек) может иметь адрес.

Answer 5

@ Скотт В чем проблема в наследстве от человека?

@Tim, как наследство здесь терпит неудачу?

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

Рекламодатель - это человек. Издатель - человек. Я предпочитаю наследство

Answer 6

Мои 2 цента ...

Когда я читаю ваш вопрос, кажется, что физический человек не является частью вашей модели. Ваша модель имеет дело с издателями и рекламодателями.

Первый. Я думаю, что физический человек (или компания) должен жить в разделенном домене «референтного уровня», который может превратиться в «уровня или партнерского репозитория».

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

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

Answer 7

(Предупреждение - чрезмерно упрощенное)

Наследование в этом случае не удалось, тест " - это" тест ..

Обычно вы спрашиваете "это" мой класс "a" <whatever> Или это "есть" <whatever>