Значение по сравнению с объектами Entity (Domain Driven Design)

Question

Я только начал читать DDD. Я не могу полностью понять концепцию объектов Entity vs Value. Может ли кто-нибудь объяснить проблемы (ремонтопригодность, производительность и т. Д.), С которыми может столкнуться система, когда объект Value проектируется как объект Entity? Пример был бы великолепен ...

Answer 1

Сводится к существенному различию, идентичность имеет значение для сущностей, но не имеет значения для объектов стоимости. Например, чье-то Имя является ценностным объектом. Сущность Customer может состоять из имени клиента (объекта значения), List OrderHistory (списка объектов) и, возможно, адреса по умолчанию (обычно это объект значения). Клиентский объект будет иметь идентификатор, и каждый заказ будет иметь идентификатор, но имя не должно быть; как правило, в пределах объектной модели идентичность адреса, вероятно, не имеет значения.

Объекты значений обычно могут быть представлены как неизменяемые объекты; изменение одного свойства объекта-значения по существу разрушает старый объект и создает новый, потому что вы не так озабочены идентичностью, как содержанием. Правильно, метод экземпляра Equals в Name возвращает «true», если свойства объекта идентичны свойствам другого экземпляра.

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

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

Вполне возможно, что даже элементы, имеющие идентичность в вашей базе данных, не имеют идентичности в вашей объектной модели. Но самый простой случай - это совокупность некоторых атрибутов, которые имеют смысл вместе. Вы, вероятно, не хотите иметь Customer.FirstName, Customer.LastName, Customer.MiddleInitial и Customer.Title, когда вы можете составить их вместе как Customer.Name; вероятно, к тому времени, когда вы подумаете о постоянстве, они будут представлять собой несколько полей в вашей базе данных, но вашей объектной модели все равно.

Answer 2

Любой объект, который в совокупности определяется всеми его атрибутами, является объектом значения. Если какой-либо из атрибутов изменяется, у вас есть новый экземпляр объекта значения. Вот почему объекты-значения определяются как неизменяемые.

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

Более простой способ провести различие состоит в том, чтобы рассматривать объекты-значения как статические данные, которые никогда не изменятся, а объекты - как данные, развивающиеся в вашем приложении.

Answer 3

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

Возьмите этот случай: вы живете в своем доме с другими людьми. Если бы мы использовали Entity для Address, я бы сказал, что будет один уникальный Address, на который ссылаются все объекты Person. Если один человек уходит, вы хотите обновить его адрес. Если вы обновите свойства объекта «Адрес», у всех людей будет другой адрес. В случае объекта значения мы не сможем редактировать адрес (поскольку он является неизменным), и мы будем вынуждены предоставить новый адрес для этого лица.

Это звучит правильно? Я должен сказать, что я был / все еще смущен этой разницей после прочтения книги DDD.

Идя еще дальше, как это будет моделироваться в базе данных? Будут ли у вас все свойства объекта Address в виде столбцов в таблице Person или вы создадите отдельную таблицу адресов, которая также будет иметь уникальный идентификатор? В последнем случае у людей, живущих в одном и том же доме, каждый будет свой экземпляр объекта Address, но эти объекты будут одинаковыми, за исключением их свойства ID.

Answer 4

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

Answer 5

Типы значений:

• Типы значений не существуют сами по себе, зависит от типов сущностей.
• Объект типа значения принадлежит объекту типа объекта.
• Срок службы экземпляра типа значения ограничен сроком службы экземпляра объекта-владельца.
• Три типа значений: базовые (примитивные типы данных), составные (адрес) и коллекции (карта, список, массивы)

Сущности:

• Типы сущностей могут существовать самостоятельно (Идентичность)
• У сущности есть свой жизненный цикл. Он может существовать независимо от любой другой сущности.
• Например: человек, организация, колледж, мобильный, дом и т. Д. Каждый объект имеет свою индивидуальность

Answer 6

Я спрашивал об этом в другой ветке и думаю, что все еще в замешательстве. Возможно, я путаю соображения производительности с моделированием данных. В нашем приложении по каталогизации Заказчик не меняется, пока ему это не нужно. Это звучит глупо - но «чтения» данных клиентов намного превосходят «записи», и поскольку многие веб-запросы все чаще попадают в «активный набор» объектов, я не хочу продолжать загружать клиентов снова и снова. Таким образом, я шел по неизменной дороге к объекту Customer - загружал его, кэшировал и обслуживал тот же самый запрос до 99% (многопоточных) запросов, которые хотят видеть Customer. Затем, когда клиент что-то меняет, найдите «редактора», чтобы создать нового клиента и лишить законной силы старый.

Меня беспокоит, что если многие потоки видят один и тот же объект клиента и он изменчив, тогда, когда один поток начинает меняться, в других возникает хаос.

Мои проблемы сейчас таковы: 1) разумно ли это, и 2) как лучше всего это сделать без дублирования большого количества кода о свойствах.

Answer 7

3 различия между Entities и Value Objects

• Идентификатор против структурного равенства: Объекты имеют идентификатор, объекты одинаковы, если они имеют одинаковые идентификатор. Объекты значения, находящиеся за пределами руки, имеют структурное равенство, мы рассмотрим два Значения объектов равны, когда все поля одинаковы. Объекты значения не могут есть идентификатор.

• Изменчивость против неизменности: Объекты-значения являются неизменяемыми структурами данных, тогда как объекты изменяются во время их время жизни.

• Срок службы: объекты значения должны принадлежать сущностям