значение по сравнению с объектами entity (domain driven design)

<p>я только начал читать ddd. я не могу полностью понять концепцию объектов entity vs value. может ли кто-нибудь объяснить проблемы (ремонтопригодность, производительность и т.д.), с которыми может столкнуться система, когда объект value проектируется как объект entity? пример был бы великолепен ...</p>

<p>сводится к существенному различию, идентичность имеет значение для сущностей, но не имеет значения для объектов стоимости. например, чье-то имя является ценным объектом. сущность customer может состоять из имени клиента (объекта значения), list <order> orderhistory (списка объектов) и, возможно, адреса по умолчанию (обычно это объект значения). клиентский объект будет иметь идентификатор, и каждый заказ будет иметь идентификатор, но имя не должно быть; как правило, в пределах объектной модели идентичность адреса, вероятно, не имеет значения.</p><p>значимые объекты обычно могут быть представлены как неизменяемые объекты; изменение одного свойства объекта-значения по существу разрушает старый объект и создает новый, потому что вы не так озабочены идентичностью, как содержанием. правильно, метод экземпляра equals в name возвращает «true», если свойства объекта идентичны свойствам другого экземпляра.</p><p>однако изменение какого-либо атрибута объекта, такого как клиент, не разрушает клиента; клиентский объект обычно изменчив. идентичность остается прежней (по крайней мере, после того, как объект был сохранен).</p><p>вы, вероятно, создаете объекты значения, не осознавая этого; каждый раз, когда вы представляете какой-либо аспект сущности, создавая детализированный класс, вы получаете объект значения. например, класс ipaddress, который имеет некоторые ограничения на допустимые значения, но состоит из более простых типов данных, будет объектом значения. emailaddress может быть строкой или объектом-значением со своим собственным набором поведений.</p><p>вполне возможно, что даже элементы, которые имеют идентичность в вашей базе данных, не имеют идентичности в вашей объектной модели. но самый простой случай - это совокупность некоторых атрибутов, которые имеют смысл вместе. вы, вероятно, не хотите иметь customer.firstname, customer.lastname, customer.middleinitial и customer.title, когда вы можете составить их вместе как customer.name; к тому времени, когда вы подумаете о постоянстве, они, вероятно, будут иметь несколько полей в вашей базе данных, но вашей объектной модели все равно.</p>

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

<p>я не знаю, правильно ли следующее, но я бы сказал, что в случае объекта address мы хотим использовать его как объект значения вместо объекта, поскольку изменения в объекте будут отражаться на всех связанных объектах ( человек например).</p><p>возьмите этот случай: вы живете в своем доме с другими людьми. если бы мы использовали entity для address, я бы сказал, что будет один уникальный address, на который ссылаются все объекты person. если один человек уходит, вы хотите обновить его адрес. если вы обновите свойства объекта «адрес», у всех людей будет другой адрес. в случае объекта значения мы не сможем редактировать адрес (поскольку он неизменен), и мы будем вынуждены предоставить новый адрес для этого лица.</p><p>это звучит правильно? я должен сказать, что я был/все еще смущен этой разницей, прочитав книгу ddd.</p><p>идя дальше, как это будет моделироваться в базе данных? будут ли у вас все свойства объекта address в виде столбцов в таблице person или вы создадите отдельную таблицу адресов, которая также будет иметь уникальный идентификатор? в последнем случае люди, живущие в одном доме, будут иметь разные экземпляры объекта address, но эти объекты будут одинаковыми, за исключением их свойства id.</p>

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

<p>я спросил об этом в другой ветке, и я думаю, что все еще в замешательстве. возможно, я путаю соображения производительности с моделированием данных. в нашем приложении по каталогизации заказчик не меняется, пока это не потребуется. это звучит глупо - но «чтения» данных клиентов намного превосходят «записи», и так как многие веб-запросы сталкиваются с «активным набором» объектов, я не хочу продолжать загружать клиентов снова и снова. поэтому я шел по неизменному пути к объекту customer - загружал его, кэшировал и обслуживал тот же самый запрос до 99% (многопоточных) запросов, которые хотят видеть customer. затем, когда клиент что-то меняет, найдите «редактора», чтобы создать нового клиента и лишить законной силы старый.</p><p>меня беспокоит, что если многие потоки видят один и тот же объект клиента и он изменчив, тогда, когда один поток начинает меняться, в других возникает хаос.</p><p>мои проблемы сейчас таковы: 1) разумно ли это, 2) как лучше всего это сделать, не дублируя большой объем кода свойств.</p>

<p><strong> типы значений: </strong> </p><ul> <li>типы значений не существуют сами по себе, зависит от типов сущностей.</li> <li>объект типа значения принадлежит объекту типа сущности.</li> <li>срок жизни экземпляра типа значения ограничен сроком жизни экземпляра объекта-владельца.</li> <li>три типа значений: базовые (примитивные типы данных), составные (адрес) и коллекционные (карта, список, массивы)</li> </ul><p><strong> объекты: </strong> </p><ul> <li>типы сущностей могут существовать самостоятельно (идентичность)</li> <li>у сущности есть свой жизненный цикл. он может существовать независимо от любого другого объекта.</li> <li>например: человек, организация, колледж, мобильный, дом и т.д. каждый объект имеет свою индивидуальность</li> </ul>

<p>3 различия между <code>entities</code> и <code>value objects</code> </p><ul> <li><p>идентификатор и структурное равенство: объекты имеют идентификатор, объекты одинаковы, если они имеют одинаковый идентификатор . значения объекты, находящиеся за пределами руки, имеют структурное равенство, мы считаем два объекта значения равными, когда все поля одинаковы значимые объекты не могут иметь идентификатор </p></li> <li><p>изменчивость против неизменности: объекты-значения являются неизменяемыми структурами данных, тогда как сущности изменяются в течение времени их существования.</p></li> <li><p>продолжительность жизни: объекты значения должны принадлежать сущностям</p></li> </ul>