А
джунгли - это тот же банан. Нет, конечно, агрегатор событий и сущность - это разные слои.
Ранее в теме упоминал про коллектор событий, имелся ввиду инстанс, с одним из аттрибутов - массив, в котором накапливаются события, в контексте вышеупомянутого проекта это массив $queue из
https://github.com/qandidate-labs/broadway/blob/master/src/Broadway/EventHandling/SimpleEventBus.php
Что вкладывается в понятие "агрегатор событий" я не понимаю тогда. Как/где располагается этот слой в архитектуре? Мы может в терминологии разошлись?
Если вспомнить, что кроме модели есть еще и контроллер, а сама модель может быть
наблюдателем, то все становится на свои места.
Я сторонник подхода худого контроллера. Контроллер генерирует команду (это именно объект), которая уходит либо в сервис либо в CommandBus с последующим вызовом соответствующего CommandHandler. Зачем подписывать модель на события контроллера? Слой доменной логики, вообще, не должен знать, что там выше и не должен обрабатывать события верхнего уровня, иначе нарушается луковая архитектура.
модель может что-то возвращать - DTO, VO, другие модели
На данный момент, действительно, что мне пригодилось для возврата, так это getId(), потому что id генерировала БД (mysql), т.к. по REST, если отправляешь POST на /users/ с данными новой учетной записи, то назад должен получить 201 код и ссылку на эту новую запись /users/:id. Но если использовать VO UserId с внешним генератором ID, то и этот метод не нужен был бы. А согласно CQRS при команде вообще ничего возвращать не нужно.
$user = new User(UserId $userId, string $name, string email);
Doctrine 2 вытаскивает данные через рефлексию, ей данный метод не нужен.
Может - да может, нужно - вопрос, требуется конкретный пример. Для read-модели данные отдельно заполняются.
DTO возвращать точно не нужно, это задача хендлера/сервиса, который получает данные из репозитория, и только при Query-запросе.
Вурдалак, благодарю за развёрнутый комментарий и примеры кода.
Я спрашивал тебя в чём «ответственность» (responsibility) модели, чтобы можно было формально понять что значит «нарушение SRP» в отношении модели.
Мне понравился вариант из статьи (см. пункт "Заключение") "оперирует данными и объектами, которые находятся внутри домена"
http://blog.byndyu.ru/2010/05/domain-driven-design.html
События я вижу как внешнее по отношению к сущности явление, скорее всего из-за того что в PHP мы не можем как-то элегантно это обработать. Хотя они больше должны быть похожи на Exception, только в положительном ключе и, следовательно, находиться внутри. Мне не нравится именно тот факт что Entity знает про некий инстанс, который обрабатывает события.
Но как ты сказал выше это именно event-модель, т.е. ключевое слово event и без их обработки в этом случае не обойтись. Я не против данного решения.
Приходит в голову такое решение:
PHP:
class User {
...
public function activate() : UserWasActivatedEvent
{
$this->is_active = true;
$this->actived_at = new DateTime();
return new UserWasActivatedEvent($this->id, $this->is_active, $this->actived_at);
}
}
...
$event = $user->activate();
$this->eventDispatcher->dispatch($event);
Вот, аналогия с Exception мне больше нравится, его мы тоже снаружи ловим через try-catch.
