В чем разница между DTO vs ValueObject vs Entity на примерах? Правильное именование классов.

[Вурдалак]

Ты путаешь, с какого это новое?

Я ничего не путаю: в PHP-мире некоторые концепции просто появляются с [приличным] запозданием. На этом форуме о DDD 3-4 года назад не упоминали, а теперь — чуть ли не каждую неделю.

основы вроде инверсии зависимостей не осознали и хардкодят такое гавно

О каком хардкоде идёт речь?

Тот же иммутэйбл в VO в php который крутится в 100500 процессах на десятках серверов, да не смешите.

Я не понял, что ты хотел сказать.

 

[Тугай]

Заказ это Entity, строки заказа это ValueObjects.
ValueObjects неизменяемый, только в том смысле, что если мы его изменили это уже другой VO. Менять никто не запрещает.
Пришел запрос с полями формы, нужно проверить, обработать или вернуть назад во view с сообщениями об ошибках. DTO - это типизированный объект
запроса.

DDD - от MVC - это то какой могла бы быть буква М. Entity, ValueObjects - это модель. DTO - это данные завернутые в объект для взаимодействия контролера с моделью и вью.

 

[Вурдалак]

Заказ это Entity, строки заказа это ValueObjects.
ValueObjects неизменяемый, только в том смысле, что если мы его изменили это уже другой VO. Менять никто не запрещает.
Пришел запрос с полями формы, нужно проверить, обработать или вернуть назад во view с сообщениями об ошибках. DTO - это типизированный объект
запроса.

DDD - от MVC - это то какой могла бы быть буква М. Entity, ValueObjects - это модель. DTO - это данные завернутые в объект для взаимодействия контролера с моделью и вью.

Вот у меня такое ощущение, что ты оставил этот комментарий, чтобы объяснить что-то самому себе.

 

[Sufir]

@Вурдалак, повторение – мать учения.

 

[fixxxer]

@AmdY, а в чем ты видишь пользу DI на уровне model?

 

[LIME]

@AmdY, а в чем ты видишь пользу DI на уровне model?

я в своем "велике" внедрял сущности фильтра (WHERE для MySQL) разных сущностей
например
SomeModel::get(new Column('name', 'value'));
SomeModel::get(new Array('name', $values));// $values = [...] means IN (...)
SomeModel::get(new Range('name', ['value1', 'value2'])); // BETWEEN
и сами сущности могли включать себе подобные
composit + decorator
чем не DI ?
если не вник в истоки темы сорь) не читал) ленивый я))
всегда есть место SOLID
как говориться кроме проблемы избыточности абстракций))
хотя думаю это был вопрос - провокация))
я благополучно повелся))

 

[Вурдалак]

@AmdY, а в чем ты видишь пользу DI на уровне model?

Да он вообще не разобрался в вопросе, видит new — говорит о хардкоде и что-то там про инверсию зависимостей. Даже в голову не приходит, что это value object'ы. Регистрировать value object'ы в контейнере что ли? Гыы.

 

[LIME]

Регистрировать value object'ы в контейнере что ли?

бывает и гибкий DI
Reflection
но формировать его всеравно лучше контейнером
все просто
локализуем действие
просто как табурет

 

[grigori]

@fixxxer, вопрос сам по себе прикольный, задумался.
где ты пишешь выбор драйвера для RCP?

 

[fixxxer]

@fixxxer, вопрос сам по себе прикольный, задумался.

это очень провокационный вопрос на самом деле

 

[AmdY]

Да он вообще не разобрался в вопросе, видит new — говорит о хардкоде и что-то там про инверсию зависимостей. Даже в голову не приходит, что это value object'ы. Регистрировать value object'ы в контейнере что ли? Гыы.

Гыы...
https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Entity/Route.php#L34, а вот сам Leg https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Entity/Route.php#L15
а вот где VO https://github.com/leopro/trip-planner/tree/master/src/Leopro/TripPlanner/Domain/ValueObject

@AmdY, а в чем ты видишь пользу DI на уровне model?

Модель и её флоу - самые динамичные вещи в проекте, требования постоянно меняются, меняется флоу, появляются ветвления и нужно несколько реализаций в зависимости от условий. Да и привычка upgrade safe, чтобы ядро можно было обновлять, а любой хардкор делает из проекта битрикс, т.к. невозможно строить пристройку без изменения кода ядра у утраты BC.

 

[grigori]

@fixxxer, конечно.
symfony диктует нам контейнеры с конфигами, yii - service locator в глобальном scope, ZF - фабрику с магическими константами

 

[Вурдалак]

Гыы...
https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Entity/Route.php#L34, а вот сам Leg https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Entity/Route.php#L15
а вот где VO https://github.com/leopro/trip-planner/tree/master/src/Leopro/TripPlanner/Domain/ValueObject

Какая разница, ты что, собираешься Route сделать сервисом? И инжектить туда Leg? Какой конфуз.

 

[Вурдалак]

Модель и её флоу - самые динамичные вещи в проекте, требования постоянно меняются, меняется флоу, появляются ветвления и нужно несколько реализаций в зависимости от условий. Да и привычка upgrade safe, чтобы ядро можно было обновлять, а любой хардкор делает из проекта битрикс, т.к. невозможно строить пристройку без изменения кода ядра у утраты BC.

Модель должна отражать текущие бизнес-требования. Чем больше ты вносишь абстракций в модель (например, избавляешься от констант, от каких-то «хардкодных» инвариантов, как тебе кажется), тем более анемичной она становится. Тем менее понятной будет эта модель, тем менее «безопасной» она будет в сохранении своих инвариантов.

Внезапно: хардкод — это не всегда плохо, а в модели даже полезно.

Между прочим, оцените абсурдность ситуации: фанат KISS говорит о том, что нужно избавляться от проклятого хардкода, но при этом меня обвиняют в overengineering'е.

 

[grigori]

@AmdY, самая динамичная часть проекта - представление.
Ветвление логики не имеет отношения к DI. Ветвление логики реализуется через абстрактную фабрику, стратегию или builder. С DI это ортогонально, потому что DI - это лишь механизм связи уже определенных объектов, а не для определения этих объектов. Стратегия, где имена классов захардкожены в switсh - это совершенно естественно.
Однако, есть моменты, где DI в модели нужен. Я и спросил про драйвер/кодек.

Единственное, с чем DI связан неразрывно - это тестирование ради тестирования

 

[Вурдалак]

@AmdY давал ссылки на сущности, и, судя по всему, именно в этом смысле речь шла про «модели», когда спрашивал @fixxxer. А @grigori похоже говорит про read models и их сериализацию?

Тут не хватает ubiquitous language.

 

[fixxxer]

Однако, есть моменты, где DI в модели нужен. Я и спросил про драйвер/кодек.

А приведи случай, когда это именно часть бизнес-логики.

@Вурдалак, не, я имел ввиду именно domain model layer, с сущностями и так все очевидно

 

[Adelf]

@fixxxer, ну так если Anemic то как там без DI то?

 

[grigori]

@Вурдалак, хорошее замечание, надо обдумать.

А приведи случай, когда это именно часть бизнес-логики.

Обработка платежей. API определяется клиентом - его выбором платежной системы.

 

[fixxxer]

@grigori, ну будет там фабрика, положим. DI тут разве что тем местом, что через него будет инжектиться фабрика куда-то там.

@Adelf, анемики идут лесом, а так я к тому и клоню, что кроме как в domain service негде, да и там спорно