DDD: помогите мне понять объекты и сущности значения

Question

Есть несколько вопросов по этому поводу, и их чтение мне не поможет.В Eric Evans DDD он использует пример адреса, являющегося типом значения в определенных ситуациях.Для компании, занимающейся почтовым заказом, адрес является типом значения, потому что на самом деле не имеет значения, является ли адрес общим, кто еще живет по адресу, просто то, что пакет прибыл по адресу.

Это имеет смыслдо тех пор, пока я не начну думать о том, как это будет сделано.Учитывая диаграмму на странице 99, он имеет это так:

+------------+
|Customer    |
+------------+
|customerId  |
|name        |
|street      |
|city        |
|state       |
+------------+

Это изменится на:

+------------+
|Customer    | (entity)
+------------+
|customerId  |
|name        |
|address     |
+------------+

+------------+
|Address     | (value object)
+------------+
|street      |
|city        |
|state       |
+------------+

Если бы это были таблицы, Address имел бы свой собственный Id, чтобы иметьотношения с клиентом, превращая его в сущность.

Является ли идея, что в реляционной базе данных они будут оставаться в одной таблице, как в первом примере, и что вы будете использовать функцииORM, чтобы абстрагировать адрес как объект-значение (например, функции компонентов nHibernate)?

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

Answer 1

Когда Эрик Эванс говорит о том, что «сущности имеют идентичность, а объекты значения - нет», он не говорит о столбце идентификаторов в базе данных - он говорит об идентичности как концепции.

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

Вы можете создать отдельную таблицу для адреса или в той же таблице в Customer

Answer 2

Является ли идея, что в реляционном База данных они будут оставаться в том же таблица, такая как в первом примере, и что вы будете использовать функции ORM абстрагировать адрес как объект значения (например, компонент nHibernate особенности)?

Да, как правило, это идея.

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

Answer 3

Да, как правило, адрес будет оставаться в той же таблице.Адрес будет отображаться примерно так:

+-----------------+
|Customer         |
+-----------------+
|customerId       |
|name             |
|address_street   |
|address_city     |
|address_state    |
+-----------------+

Если бы Адрес был сущностью, то, как вы сказали, он был бы в отдельной таблице.Если два одинаковых клиента связаны с одним и тем же объектом адреса, то изменение атрибута этого адреса повлияет на обоих клиентов.Однако реализация VO будет влиять только на одну или другую.

Answer 4

Мне лично наплевать на наличие идентификатора на объектах-значениях, если они корректно переопределяют сравнение на равенство (объекты-значения различаются по значению, а не по идентичности).

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