Entity vs Object Value?

Question

[BonBon Slick]

Не совсем пойму что и когда применять.
Я так понимаю что то одно? Или можно то и другое? И как правильно? Когда надо? Почему?

Answer 1

[vova07]

Приветную!

Попробую быть краток.

Сущность - это объект содержащий набор данных с уникальным идентификатором. По мимо этого простого правила, есть еще одно немаловажное: данный объект имеет цикл жизни, который может быть описан поведенческими методами.

Value Object - это объект содержащий набор данных (immutable). Ничего не гарантирует уникальность, они не имеют цикла жизни и не содержат поведенческие методы, а самое главное что они неизменны (immutable).

А теперь попробуем ответить на ваши вопросы (я извиняюсь за грубость но они чуток некорректны по этому и ответы не очевидны):

Я так понимаю что то одно?

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

Или можно то и другое?

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

И как правильно?

Правильно, понятие растяжимое и как я сказал все зависит от агрегата который вы пишите, от контекста который вы моделируете,и от бизнес логики которая есть в вашем домене. Используйте то что решает ваши нужды.

Когда надо?

Тоже самое, тут нет правильного ответа. Надо тогда когда ваша бизнес логика начинает работать.

Comments

[yurygolikov]

VO - вполне может содержать поведенческие методы. Откуда вы взяли, что он не может?

[vova07]

@yourygolikov что-бы не допустить недопонимания которое я наблюдаю я попробую объяснить что я имею введу под поведенческие методы.

Как я уже сказал у VO нет цикла жизни (life cycle), они всегда неизменны (immutable) и у них нет состояния (stateless) .

Учитывая это VO никогда не будут содержать поведенческие методы (behavior methods) то есть они лишены какого либо поведения (behavior) или состояния (state). Но это не значит что VO не содержат вообще методов (это совсем другое). Они вполне могут содержать разные методы которые просто делают операции без манипуляции состояния. Например сравнение на идентичность содержащего набора данных, сравнение определенных значений, фактори методы которые создают новые VO на основе текущих данных, разные инкапсуляции логических проверок, и много другое что лишено поведений или учета состояния. (Поведение в моем понимании это манипуляция состояния. )

Надеюсь я прояснил ваше недоумение, и исправил ошибку в своем сомнительном выражении.

[ddd329]

vova07,

Как я уже сказал у VO нет цикла жизни (life cycle), они всегда неизменны (immutable) и у них нет состояния (stateless) .

Как же у ValueObject нет состояния если они содержат данные? Состояние - это совокупность значений объекта, изменив например одно значение, то измениться состояние, но у ValueObject состояние должно быть неизменным (immutable), но оно есть, т.к. содержит данные...

Учитывая это VO никогда не будут содержать поведенческие методы (behavior methods) то есть они лишены какого либо поведения (behavior) или состояния (state).

Почему ValueObject не может содержать поведенческие функции? Вполне может, т.к. не является простым контейнером данных таким как DTO. Единственное то, что поведение ValueObject не может изменять свое состояние.

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

Пусть манипулирую состояние, но только его не изменяют.

Например сравнение на идентичность содержащего набора данных

Идентичность определяется у объектов-сущностей присвоением идентификатора, а у объектов-значений - эквивалентность, которая определяется совокупностью всех значений

[vova07]

ddd329, мне кажется либо вы меня не понимаете, либо я вас.

Как же у ValueObject нет состояния если они содержат данные? Состояние - это совокупность значений объекта, изменив например одно значение, то измениться состояние, но у ValueObject состояние должно быть неизменным (immutable), но оно есть, т.к. содержит данные...

То что по вашим словам у VO есть изначальное состояние которое по причине содержание данных является по умолчанию, я не трактирную идентично. Это конечно правда, но это субъективное мнение и интерпретация, и если вы прочтёте внимательно мой коммент ещё раз, то заметите что я там специально написал английский перевод (stateless) - так как не хочу вводить никого в заблуждения своими непрофессиональными переводами.

Почему ValueObject не может содержать поведенческие функции? Вполне может, т.к. не является простым контейнером данных таким как DTO. Единственное то, что поведение ValueObject не может изменять свое состояние.

Мне кажется вы читаете между рядами. Привожу специально отрывок из моего коммента чтобы вы поняли что это ваши личные утверждения: (Специально выделил жирным факториям методы о которых вы намекаете.)

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

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

Пусть манипулирую состояние, но только его не изменяют.

Если вы именно о манипуляции собственного состояния, то я вас не понимаю. невозможно манипулировать состоянием без её изменения. Но еще раз повторяю, я уже написал о фактори методах, для имитации манипуляции состояния, которые могут присутствовать в VO, но на самом деле они генерируют новые инстансы вообще. (Генерируют проекцию нового этапа жизни)

Если я где-то что-то недопонял, я извиняюсь, но комментирую ровно то что я читаю.

[ddd329]

vova07,

Если вы именно о манипуляции собственного состояния, то я вас не понимаю. невозможно манипулировать состоянием без её изменения.

Нет проблем, разберем пример.
Есть доменный класс Rectangle, который представляет собой прямоугольник и имеет всего два свойства Width(ширина) и Height(высота). Два прямоугольника считаются эквивалентыми друг другу, если их ширина и высота у обоих одинакова. Различать их между собой не имеет для нас смысла, поэтому Rectangle будет являться ValueObject'ом.
Значения ширины и высоты определяют его состояние. Говорите что не может содержать поведенческие функции/методы, вот пожалуйста: нам необходимо вычислить площадь прямоугольника, вопрос кто должен этим заниматься? Да сам Rectangle и будет это делать реализовав функцию CalcSquare, которая перемножит ширину на высоту и вернет вам результат. Вот и получается что Rectangle манипулирует своим состоянием чтобы выполнить поведенческие функции, но не изменят его.

[vova07]

ddd329, я согласен с вами. Пример верный и ваше утверждение тоже. Только я не понимаю почему вы посчитали что я думаю иначе?!

Я специально привел отрывок из своего первого сообщения где я написал тоже самое, и сделал акцент на том что сама VO может содержать такие подобия методов без ограничений. Только вы кажется путаете понятия. И я еще раз привожу отрывок из другого моего коммента:

Учитывая это VO никогда не будут содержать поведенческие методы (behavior methods) то есть они лишены какого либо поведения (behavior) или состояния (state). Но это не значит что VO не содержат вообще методов

Повторяю чтобы было понятно, для меня подсчет площади это не поведение. Это обычная математическая операция. Поведение в моем понимании это совсем другое, для сравнительного примера изменение площади это поведение которое меняет какое-то состояние. Но невинные операции которые оперируют значениями определенного состояния я не трактирную как поведенческие вообще. Это обычные методы, которые имеют другие эффекты.

Для справки под поведенческие методы я подразумеваю русский перевод вот этого: behavioral methods. Если это вас как-то запутало то я за это извиняюсь!

[ddd329]

vova07,
Помнится, я где-то читал что ОБЪЕКТ-ЗНАЧЕНИЕ определяется данными и СУЩНОСТЬ определяется своим поведением, наверно где-то и вы это прочитали...
Ну давайте сделаем Rectangle сущностью и введем свойство ReactangleId, и разрешим изменять напрямую ширину и высоту.

Покажите какими поведенческими метода (behavioral methods) этот класс может обладать?

Answer 2

[ddd329]

Вот например вы пишите программу для СТО, которая обслуживает автомобили. У вас есть понятие "Автомобиль", которое в коде Вы выражаете через доменный объект Car. Car это сущность или объект-значение? Начинаем рассуждать, если СТО обслуживает два полностью одинаковых автомобиля, т.е. марка, цвет, параметры двигателя полностью совпадают, несмотря на это мы должны их различать в программе, потому что на одном мы меняли колодки, а на втором замена масла, и это должно учитываться для каждого конкретного автомобиля, чтобы как минимум сохранить всю историю обслуживания. Как мы будем различать их в программе? Мы должны определить идентификационное свойство, возьмем грубо гос. номер, я конечно понимаю что номер со временем может поменяться на машине, например при продаже, но тем не менее он является уникальным атрибутом сущности и не может быть одинаковым на разных автомобилях одновременно. И Car - это именно СУЩНОСТЬ, так как имеет свой идентификатор представленным в виде гос. номера.
Хорошо. Выше мы упоминали о двигателе. Выразим понятие "Двигатель" через доменный класс Engine. Чем является доменный класс Engine объектом-сущности или объектом-значением? Что выбрать? Это зависит от потребностей данного бизнеса к вашей программе. Можно сделать Engine объектом-значением, который имеет свои параметры, и два двигателя считаются одинаковыми, если значения всех параметров у них совпадают.
Но Engine можно сделать и объектом-сущностью, например СТО ремонтирует двигатели и для них важно не только для какого именно автомобиля, но и для какого конкретного двигателя, чтобы сохранить всю историю его ремонта. Со временем на автомобиле двигатель может быть заменен на новый, и вся история его ремонта начнется с "чистого листа". Будем считать что это нам подходит, и делаем Engine сущностью.
В нашем коде уже есть два понятия Car и Engine, которые оба являются сущностями. Теперь надо выбрать АГРЕГАТ(Ы). Вопрос: Car и Engine это и есть АГРЕГАТЫ, где Car просто ссылается на Engine, или нет? АГРЕГАТ определяет границы изменения, поэтому если СТО ремонтирует двигатель, то следовательно и ремонтирует автомобиль. Значит эти две сущности входят в один АГРЕГАТ, где корнем будет скорее всего будет сущность Car.