Yii Framework

Для определения, какому классу назначить обязанность по логину я бы воспользоваться шаблоном GRASP Information Expert. У кого больше всего данных для выполнения этой операции? У юзера - значит пусть будет User::login(). Несогласен, давайте разберем простейший логин, на вход поступает имя пользовате...

В Implementing domain-driven design можно найти примеры отправки email по доменному событию в application сервисе. Т.е. отправка email не безнес логика? Если доменный эксперт сказал - после n должно быть отправлено сообщение пользователю, то это разве не должно находить отражение в домене? Владелец...

Ну тогда будет сервис с внутренним состоянием, вроде бы нормально.
PS пользуюсь синглтоном, так что не могу ответить.

Ну так а в каком доменном объекте возникнет событие UserLogged ? По моему, это как раз тот случает когда бизнес логика не принадлежит какой либо конкретной сущности, и мы можем разместить ее в сервисе. Соответственно их должно быть минимальное количество. Лучше если их нет вообще. Вот тут не совсем ...

sda писал(а): ↑2017.12.26, 02:14 А вообще я не понимаю, зачем здесь доменный сервис. Задача решается обычным application сервисом. Например так.

А почему вы против доменного сервиса? Допустим у меня после логина должно выбрасываться доменный евент, как быть?

Ну да, как описал authenticate принимает $authSession, согласен, но login то user'a принимает. Тут меня больше интересует то, что в app layer лежит интерфейс, а реализуется он в infrastructure, это правильный подход? В твоем примере помойму напутанно: 1) SessionAuthenticationService в примере по сут...

Лучше юзера, тк login($user) логично и соответствует терминам предметной области. И должен ли агрегат юзера содержать в себе свои сессии? Или сессия должна содержать юзера? Я за 2й вариант, невижу причин юзеру знать о существование сессии (кстати нужно ли знать домену о существование сессии? видимо ...

В app service буду получать юзера каким то образом, например по токену (или этим должен заниматься инфраструктурный сервис?) и передавать его доменному сервису AuthenticationService. Можно заинжектить в app сервис репозитроий class LoginCommand { public function execute ($dto) { $member = $this->ge...

В теории да, ведь инфраструктура знает о домене, но передачи дто будет нарушить ubiquitous language в терминах которого спроектирован доменный сервис. Думаю так. В любом случае что мешает сохранить цепочку инфраструктура -> app сервис -> доменный сервис? App сервис у нас будет конкретный сценарий пр...

Нет, это доменный сервис

Не, что-то не складывается... Какое поведение у токена может быть? Да ни какого, это просто VO. Да никакого, а в чем не состыковка? Ну юзер тоже сам себя не залогинит в систему, помойму это система (в данном случае authentificator) должна принять решение залогинить юзера или отклонить. Вот чтобы не...

Я бы еще вынес в доменный сервис архивацию/восстановление. У себя так и делал, но у меня сущность и сущность в архиве это 2 разные сущности (через sti) тк сущность в архиве меняет свое поведение и тоже участвует в бизнес логике. Тогда логика из сущности перекочует в сервис. Но она все равно будет ря...

Нет, думаю пароль должен быть в юзере, но генерация пароля в доменном сервисе который будет реализовываться в инфраструктурном слое, скорее всего. Кстати по поводу bounded context, тема сложна, возможно frontend и admin можно рассматривать как 2 разных контекста, но тогда соответственно у нас будут ...

Вот с контекстами я практически незнаком. Есть пример выделения контекстов с примерами организации этого всего в коде? примеры с bounded context есть в конце ddd in php, правда к вашему вопросу это не особо применимо, помойму. Я это к тому что домен не должен знать в админке ли его модель используе...

Ну так почему не перенести ответственность в другой класс? Как еще делать декомпозицию год объекта? Токенами должен обязательно юзер управлять?
И еще по сути вопроса, админка/фронтенд это ведь чисто инфраструктурные вещи, в домене у вас контекст в котором работает модель = bounded context.

login, logout изменяют внутреннее состояние пользователя?

login, logout, authenticate точно можно вынести в доменный сервис, Authentifier какой нибудь.
Так же archive/reinstate, если я правильно понял, тоже можно в доменный сервис. Ну и revokeAccess, хотя тут по разному можно.

Хм, да, так и есть, спасибо большое что прояснили. Теоретически, в контесте разрабатываемого модуля, я думаю можно рассматривать и Y как агрегат, то есть множество Y находятся в одном контексте X. Тогда задаче по смене владельца будет решаться $y->changeOwner($newContext) и вся логика тогда уйдет в ...

Если я вас правильно понял то должен работать такой вот код : $y = $x1->ys->get(0); $x1->ys->remove(0); $x2->ys->add($y); $em->flush(); Но он не работает, выполняется как ожидаю только если добавить перед флашем $y->changeOwner($x); Настройки мапинга дефолтные из дока, за исключением того что orphan...

Таблица X, таблица Y с полем x_id для связи