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

Question

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

**Publishers root entity 
Advertiser root entity**

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Тогда каждый филиал может иметь адрес, а каждый контакт (лицо) может иметь адрес.

Answer 5

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

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

Answer 6

Вы должны отдать предпочтение композиции, а не наследованию .

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

Answer 7

(предупреждение - слишком упрощенно)

Наследование в этом случае не проходит тест "is" ..

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