Это надуманный пример, смысл вопроса - как правильно уйти от anemic models.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Как назвать метод?
- Автор темы Vano
- Дата начала
Вурдалак
Продвинутый новичок
А че гуглить-то, ты используешь термины, значения которых сам не понимаешь и трактуешь как тебе хочется. Суть проблемы — получить поведение в сущности с помощью внешнего сервиса. Ты говоришь, что поможет aggregate root, который тоже сущность, ты не понял вопроса?
Последнее редактирование:
я понял, что не в теме
hell0w0rd
Продвинутый новичок
Ты серьезно, или опять троллишь?$user->changePasswordHash($hash)?
Хотя, если есть Security сервис...
Последнее редактирование:
whirlwind
TDD infected, paranoid
Чейта не видел ничего про внешний сервис. Что за внешний сервис еще?
Чем отличается анемичная модель от активной (или богатой - что мало о чем говорит). И где находится сервисная логика в активной модели. Она находится в сущностях. Но если лепить решение всевозможных проблем какие только могут возникнуть в рамках этих entities, то при большом количестве задачи будет Ж. К томуже лепить их можно, пока они не ссылаются друг на друга.
Получить поведение сущности с помощью внешнего сервиса, это создать контекст проблемы. Это очень легко понять, на примере циклических ссылок. Когда появляется ситуация циклических ссылок, то есть не совсем понятно кто от кого должен зависить и в какой класс добавлять метод. Это ситуация для разруливания с помощью сводного корня. Например, строки заказа зависят от заказа физически но не принципиально. Принципиально, это заказ содержит строки, а не наоборот. Реализовано может быть по-разному, но вся соль, что бы не колыхать этими проблемами потребителя. Что бы сделать реализацию ясной и прозрачной, используется сводный корень. Сечешь? Теперь на примере с чем-то имеющем связь с юзером и каким-то значением. Очевидно, что это "какое-то" значение можно охарактеризовать неким термином предметной
PS. Заметил такую штуку. Мода что ли пошла, пободаться насчет терминологии. Не совсем понимаю, это споры теоретиков чтоли? С практической точки зрения успешная архитектура это устойчивая к любым изменениям без лишнего перепила. Какая блин разница как оно называется с точки зрения потребительского кода? Сегодня этот класс был stateless и по этому назывался сервисом, а завтра мы решили кэшернуть для скорости и оно резко превратилось в entity? Да я вас умоляю, всем верхним по-х.
Последнее редактирование:
Вурдалак
Продвинутый новичок
А, так ты про Ерёму. http://phpclub.ru/talk/threads/Как-назвать-метод.79902/page-2#post-721827
Не вся, есть понятие domain service.
Речь идёт о примерно такой зависимости: http://thinkbeforecoding.com/post/2009/03/04/How-not-to-inject-services-in-entities
Можно я не буду тебе отвечать, если ты говоришь о своём?
А ещё раньше трава была зеленее. Вопрос терминологии был актуален всегда. Если ты говоришь на своём собственном языке, который понятен только тебе, то грош цена твоим тут высерам, потому что тебя никто не поймёт. Тот же ubiquitous language среди программистов. Если тебе насрать на терминологию, то будь последовательным и плюнь в лицо представителю бизнеса, который скажет, что «в нашей предметной области такое название будет некорректно».
Вурдалак
Продвинутый новичок
Я про что-то типа http://culttt.com/2014/09/29/creating-domain-services/
Вурдалак
Продвинутый новичок
Действительно, всё решаем как назвать метод.
whirlwind
TDD infected, paranoid
Товарищ, мне твои наезды по барабану. В нашем бизнесе круче тот, кто дольше и успешнее работает, а не тот кто умело цепляется к словам. Ты думаешь что entity это паттерн весь цимус которого must be persistent? Ну продолжай есть кактусы в попытках понять DDD.
Redjik
Джедай-мастер
Вброс по поводу репозиториев.
Считаю, что репозитории должны быть на уровне домена, безусловно без непосредственной реализации.
С одной стороны, мы работаем с Доменом, с другой - мы уже пишем на PHP, и от этого никуда не деться - своеобразный слой инфраструктуры уже заложен в Домен... как и заложены ограничения PHP.
Раз PHP призван для того, чтобы умирать, то у нас должен быть механизм для сохранения и восстановления состояния Entity.
Мы заранее должны включить это в бизнес логику приложения.
Что думаете?
Считаю, что репозитории должны быть на уровне домена, безусловно без непосредственной реализации.
С одной стороны, мы работаем с Доменом, с другой - мы уже пишем на PHP, и от этого никуда не деться - своеобразный слой инфраструктуры уже заложен в Домен... как и заложены ограничения PHP.
Раз PHP призван для того, чтобы умирать, то у нас должен быть механизм для сохранения и восстановления состояния Entity.
Мы заранее должны включить это в бизнес логику приложения.
Что думаете?
Redjik, ты про это? https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Contract/TripRepository.php
А причем тут domain? Ты же не будешь на уровне домена делать $em->persist. А всякие get/add, которые к персистенции отношения не имеют - ну ага.
Невалидный аргумент. Может, у меня реализация на ReactPHP будет.
Последнее редактирование:
Sufir
Я не волшебник, я только учусь
Если не ошибаюсь, то по Эвансу репозитории как раз вполне однозначно и являются частью домена. Ну, в домене по сути только интерфейс, а реализация работы с БД или другим хранилищем уже в инфраструктуре, конечно. Могу ошибаться, Эванса читал давно и так и не дочитал, отложил и руки не дошли вернуться...
Лично мне это представляется как-то так:
PHP:
$repository = new Domain\UserRepository();
$user = $repository->get();
$user->setEmail('qwerty@qwerty');
$repository->save($user);
// А на уровне инфраструктуры что-то такое...
Infr\MySQLStorage
Infr\MongoStorage
Infr\PgStorageRedjik
Джедай-мастер
ну это с одной стороны да, но как бы объекта как такого в пыхе не существует, ну или существует - но очень короткое время, то есть я себе так представляю ситуацию
скажем на Java - у нас есть несколько сущностей один ко многим, напрашивается observer для оповещении об изменении состояния
в Пыхе это оверхед создаст... проще оповещать через репозиторий не?
я понимаю что это говнистый костыль, который идет в разрез с классическим представлением домена, но это же пых
скажем на Java - у нас есть несколько сущностей один ко многим, напрашивается observer для оповещении об изменении состояния
в Пыхе это оверхед создаст... проще оповещать через репозиторий не?
я понимаю что это говнистый костыль, который идет в разрез с классическим представлением домена, но это же пых