День 1238. #ЗаметкиНаПолях #DDD
Сущности и Объекты-Значения: Полный Список Различий. Окончание
Начало
Как распознать объект-значение в вашей модели предметной области?
К сожалению, нет никаких объективных признаков, по которым вы могли бы узнать, это. Является ли понятие объектом-значением или нет, полностью зависит от предметной области: понятие может быть сущностью в одной модели предметной области и объектом-значением в другой.
В примере из предыдущего поста мы относимся к деньгам взаимозаменяемо, что делает это понятие объектом-значением. В то же время, если мы создадим программу для отслеживания потоков наличных, нам нужно будет обрабатывать каждую отдельную купюру отдельно, чтобы собирать статистику по каждой из них. В этом случае понятие денег было бы сущностью, которую мы, вероятно, назвали бы Note (Банкнота).
Если вы можете безопасно заменить экземпляр класса другим экземпляром с таким же набором атрибутов, это хороший признак того, что перед вами объект-значения. Можно сравнить объект-значения с числом. Вам не важно является ли число 5 тем же числом 5, которое вы использовали в другом методе. Т.е. это объект-значение. Если ваше понятие ведёт себя как число, то это объект-значение.
Как хранить объекты-значения в БД?
Допустим, у нас есть два класса в нашей модели предметной области: сущность Person и объект значения Address:
// Сущность
public class Person
{
public int Id { get; set; }
public string Name { get; set; }
public Address Address { get; set; }
}
// Объект-значение
public class Address
{
public string City { get; set; }
public string ZipCode { get; set; }
}
Один из вариантов хранения: добавить в Address поле Id и хранить в отдельной таблице. Это правильно с точки зрения БД, но имеет два недостатка:
1) Address содержит идентификатор, т.е. мы предоставляем классу Address некоторую идентичность. И это нарушает определение объекта-значения.
2) Мы потенциально можем отделить объекты-значения от сущностей. Address теперь может жить сам по себе, потому что мы можем удалить строку Person, не удаляя соответствующую строку Address. Кроме того, вы можете выбрать объект Address из таблицы отдельно от объекта Person. Это нарушило бы другое правило, согласно которому время жизни объектов-значений должно полностью зависеть от времени жизни их родительских сущностей. Получается, лучшее решение* — встроить поля из таблицы Address в таблицу Person.
*Здесь надо заметить, что ORM системы, вроде Entity Framework, позволяют сохранять объекты-значения в отдельные таблицы, сохраняя при этом абстракцию объекта-значения.
Предпочитайте объекты-значения сущностям
Всегда отдавайте предпочтение объектам-значениям, а не сущностям. Объекты-значения являются неизменяемыми и более лёгкими, чем сущности, поэтому с ними легче работать. В идеале вы должны помещать большую часть бизнес-логики в объекты-значения. Сущности будут действовать как оболочки для них и представлять более высокоуровневую функциональность.
Может случиться, что то, что вы сначала рассматривали, как сущность, по сути является объектом-значением. В этом случае не стесняйтесь реорганизовать модель предметной области и преобразовать сущность в объект-значение.
Итого
- Сущности имеют свою внутреннюю идентичность, а объекты-значения — нет.
- Понятие равенства идентификаторов относится к сущностям; понятие структурного равенства относится к объекты-значениям; понятие ссылочного равенства относится к обоим.
- Сущности имеют историю; объекты-значения имеют нулевую продолжительность жизни.
- Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить сам по себе.
- Объекты-значения должны быть неизменяемыми; сущности почти всегда изменяемы.
- Чтобы распознать объект-значение в модели предметной области, мысленно замените его числом.
- Всегда отдавайте предпочтение объектам-значениям, а не сущностям в вашей модели предметной области.
Источник: enterprisecraftsmanship.com/posts/e…ferences
