Я щойно почав читати DDD. Я не можу повністю зрозуміти концепцію об’єктів сутності проти вартості. Чи може хтось пояснити проблеми (ремонтопридатність, продуктивність тощо), з якими може зіткнутися система, коли об’єкт значення проектується як об’єкт сутності? Приклад буде чудовим ...
Відповіді:
Зведене до істотного розрізнення, ідентичність має значення для сутностей, але не має значення для об’єктів вартості. Наприклад, чиєсь Ім’я є об’єктом цінності. Сутність замовника може складатися з імені замовника (об'єкт значення), List <Order> OrderHistory (перелік об'єктів) і, можливо, адреси за замовчуванням (зазвичай це об'єкт значення). Організація замовника мала б ідентифікатор, і кожне замовлення мало б ідентифікатор, але ім’я не повинно; як правило, в рамках об'єктної моделі ідентичність Адреси, мабуть, не має значення.
Об’єкти вартості, як правило, можуть бути представлені як незмінні об’єкти; зміна однієї властивості об’єкта значення по суті руйнує старий об’єкт і створює новий, оскільки ви не так зацікавлені в ідентичності, як у вмісті. Правильно, метод екземпляра Equals у Name буде повертати значення "true", якщо властивості об'єкта ідентичні властивостям іншого екземпляра.
Однак зміна якогось атрибута такої сутності, як Клієнт, не знищує клієнта; сутність клієнта, як правило, змінюється. Ідентичність залишається незмінною (принаймні, коли об’єкт зберігався).
Можливо, ви створюєте цінні об’єкти, не усвідомлюючи цього; у будь-який час, коли ви представляєте якийсь аспект сутності, створюючи детальний клас, ви отримуєте об’єкт значення. Наприклад, клас IPAddress, який має певні обмеження щодо дійсних значень, але складається з більш простих типів даних, буде об'єктом значення. Адреса електронної пошти може бути рядком або об’єктом значення зі своїм набором поведінки.
Цілком можливо, що навіть елементи, які мають ідентифікацію у вашій базі даних, не мають ідентичності у вашій об’єктній моделі. Але найпростіший випадок - це сукупність деяких атрибутів, які мають сенс разом. Ви, мабуть, не хочете мати Customer.FirstName, Customer.LastName, Customer.MiddleInitial і Customer.Title, коли ви можете складати їх разом як Customer.Name; до того часу, коли ви задумаєтеся про збереження, вони, мабуть, будуть кількома полями у вашій базі даних, але вашій об’єктній моделі все одно.
int[1]може бути незміненим змінним значенням, незмінним незмінним значенням (якщо жодна з речей, що містять посилання, ніколи не буде писати до нього) або сутність (якщо існують два або більше посилань, і одне з них може використовуватися для запису значення, які можна прочитати, використовуючи інші). На жаль, я не знаю жодної мовної підтримки в Java або .NET для запобігання випадковому перетворенню об’єктів класу, які інкапсулюють змінні значення, у сутності.
Будь-який об'єкт, який колективно визначений усіма його атрибутами, є об'єктом цінності. Якщо будь-який з атрибутів зміниться, у вас буде новий екземпляр об’єкта значення. Ось чому об’єкти значення визначаються як незмінні.
Якщо об'єкт не повністю визначений усіма його атрибутами, тоді існує підмножина атрибутів, що складають ідентичність об'єкта. Решта атрибути можуть змінюватися без перевизначення об'єкта. Цей об'єкт не може бути визначений як незмінний.
Більш простий спосіб зробити розрізнення полягає в тому, щоб розглядати цінні об’єкти як статичні дані, які ніколи не змінюватимуться, а сутності як дані, що розвиваються у вашому додатку.
Типи значень:
Юридичні особи:
Я не знаю, чи правильно вказане нижче, але я б сказав, що у випадку з об'єктом Address ми хочемо використовувати його як об'єкт значення, а не як Entity, оскільки зміни в сутності відображатимуться на всіх пов'язаних об'єктах ( наприклад, Особа).
Візьмімо цей випадок: Ви живете у своєму будинку разом з іншими людьми. Якби ми використовували Entity для Адреси, я б стверджував, що існує одна унікальна Адреса, на яку посилаються всі об’єкти Person. Якщо одна людина переїжджає, ви хочете оновити її адресу. Якби ви оновили властивості сутності адреси, усі люди мали б іншу адресу. У разі об’єкта вартості ми не зможемо редагувати Адресу (оскільки вона незмінна), і ми будемо змушені надати нову Адресу для цієї Особи.
Це правильно звучить? Потрібно сказати, що я все ще бентежив цю різницю після прочитання книги DDD.
Йдучи на крок далі, як це змоделюється в базі даних? Чи мали б ви всі властивості об’єкта Address як стовпці в таблиці Person, чи створили б окрему таблицю Address, яка також мала б унікальний ідентифікатор? В останньому випадку люди, які живуть в одному будинку, мали б різні екземпляри об’єкта Address, але ці об’єкти були б однаковими, за винятком властивості їх ідентифікатора.
Я запитав про це в іншій темі, і думаю, що я все ще розгублений. Можливо, я плутаю міркування продуктивності з моделюванням даних. У нашому додатку для каталогізації Клієнт не змінюється, доки йому це не потрібно. Це звучить безглуздо, але "читання" даних клієнтів значно перевищує "записи", і оскільки багато веб-запитів потрапляють на "активний набір" об'єктів, я не хочу продовжувати завантажувати клієнтів раз за разом. Отже, я прямував незмінною дорогою до об’єкта Клієнта - завантажуй його, кешуй і подавай той самий на 99% (багатопотокових) запитів, які хочуть бачити Клієнта. Потім, коли клієнт щось змінює, отримайте "редактор", щоб створити нового Клієнта та анулюйте старого.
Мене турбує, якщо багато потоків бачать один і той самий об'єкт замовника, і він змінюється, тоді, коли один потік починає змінюватись, у інших виникає хаос.
Мої проблеми зараз полягають у тому, 1) чи це обґрунтовано, і 2) як найкраще це зробити, не дублюючи багато коду про властивості.
3 різниця між EntitiesіValue Objects
Ідентифікатор проти структурної рівності: сутності мають ідентифікатор, сутності однакові, якщо вони мають однаковий ідентифікатор. Об'єкти вартості, що знаходяться поза рукою, мають структурну рівність, ми вважаємо два об'єкти значення рівними, коли всі поля однакові. Об'єкти значення не можуть мати ідентифікатор.
Змінюваність проти незмінності: об’єкти вартості - це незмінні структури даних, тоді як сутності змінюються протягом свого життя.
Тривалість життя: Цінні об’єкти повинні належати суб’єктам господарювання
У дуже простому реченні, я можу сказати, ми маємо три типи рівності:
Рівність ідентифікатора стосується лише сутності, а структурна рівність стосується лише об’єкта вартості. Насправді в Value Objects немає ідентифікатора, і ми можемо використовувати їх як взаємозамінні. також об'єкти значень повинні бути незмінними, а сутності можуть бути змінними, і об'єкти значень не матимуть таблиці найменувань у базі даних.