Типа того.

Во-первых, соглашусь с тем, что место обработки отложенных событий надо выбирать вручную. Но мне не нравится, что некий entity что-то знает о событиях. Это уже не SRP. Если это что-то вроде ActiveRecord, который все про свой flow знает, то туда и так инжектится DBAL, и заинжектить еще 1 сервис не должно быть проблемой. Если же это DTO, то накапливать эвенты было бы логичнее в репозитории. Мне кажется, что в этом кейсе не совсем валидно отправлять дважды эвент об изменении значения, т.к. мы даже не пытаемся сохранить эти данные куда-то:

$value = $entity->getValue();
$entity->setValue($newValue);
$entity->setValue($value);

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

Я вот так примерно использую (трейт в сущности Comment):

final class CommentService
{
    private CommentRepositoryInterface $commentRepository;
    private EventDispatcherInterface $eventDispatcher;

  ...

    public function create(string $threadId, string $userId, string $body, ?string $byUserId = null): Comment
    {
       ...

        $comment = new Comment(
            UuidHelper::generateTimestampFirstCombUuid4(),
            $thread->getId(),
            $userId,
            $body,
            $byUserId,
        );

        $this->commentRepository->save($comment);

        $this->releaseEvents($comment);

        return $comment;
    }
  
  ...

    private function releaseEvents(Comment $comment): void
    {
        foreach ($comment->releaseEvents() as $event) {
            $this->eventDispatcher->dispatch($event);
        }
    }
}

@samdark удаление отсюда errorLevel мне кажется неверным - т.к. изначально уровень был 1, а по умолчанию псалм выставляет 2
https://github.com/yiisoft/security/blob/master/psalm.xml

Можно регулировать между уровнем 1 и 2 с помощью параметра totallyTyped, но он устарел
https://psalm.dev/docs/running_psalm/configuration/#totallytyped

вот логика псалма
https://github.com/vimeo/psalm/blob/16bfbd9224698bd738c665f33039fade2a1a3977/src/Psalm/Config.php#L916

final class CommentService
{
    private CommentRepositoryInterface $commentRepository;
    private EventDispatcherInterface $eventDispatcher;

  ...

    public function create(string $threadId, string $userId, string $body, ?string $byUserId = null): Comment
    {
       ...

        $comment = new Comment(
            UuidHelper::generateTimestampFirstCombUuid4(),
            $thread->getId(),
            $userId,
            $body,
            $byUserId,
        );

        $this->commentRepository->save($comment);

        $this->releaseEvents($comment);

        return $comment;
    }
  
  ...

    private function releaseEvents(Comment $comment): void
    {
        foreach ($comment->releaseEvents() as $event) {
            $this->eventDispatcher->dispatch($event);
        }
    }
}

Вот да, мне кажется, создание эвентов стоит из коммента в репозиторий вынести

Это как? У репозитория нет данных чтобы сделать события же

Входные параметры - это не оно?

Так это не в репозитории. Это в сервисе. В репозиторий улетает только сама сущность

>.< да, попутал. Я такие сервисы репозиториями и зову)

хотя. в этом конкретном случае и откладывать ничего не надо будет

Мне кажется событие должно генерться там где оно происходит. А происходит оно в сущности :)

в моем видении в сущности ничего не происходит, происходит в сервисе)

А смысл сущности тогда? Просто DTO

Ну да

Я стараюсь логику в сущности делать, только если крупное что-то выношу в сервис

Это у тебя похоже анемичная модель выходит) вообще я в эту тему начал плотно последнее время погружаться, сижу книжки читаю)))

В целом ситуация выглядит как два разных взгляда на один хак) Еще бы мнений добавить.