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

Но сущность ими не пользуется, а выступает просто хранилищем

Не парьтесь, это довольно популярный стайл работы с доменными событиями.

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


public function doSomething(string $param1, SomeVO $param2, InterfaceEventStorage $storage): void
{
   //do some logic
   $storage->add(new DomainEvent($this)); // как по мне херово передавать саму сущность в ивент, но дело ваше =)
}

она их генерирует... ты же не говоришь, что вот генератор - херовая штука, данные генерит\возвращает, но сам ими не пользуется

Можно в аргументы методов принимающих сообщения также передавать контекст и через него событиями работать.

Подход с внешним стораджем геморный и просто куча лишнего кода не понятно зачем

Вот если бы в пыхе были приватные классы можно было бы DomainEventProducerInterface сделать внутренним для условного пакета Domain
соотвесвенно юзать его мог бы только этот пакет и не протекали бы эти сущности наружу. Клиенту сущности было бы непонятно что там хранятся какие-то ивенты

но я обычно просто вешаю пхпдок
@internal и все =)

Думаю, что передавать сущность в событие - не так плохо, как таскать везде EventStorage. Ведь если завтра надо будет добавить в  методе foo генерацию события - нужно везде, где метод foo вызывается, протащить в аргументы этот сторедж, хотя с точки зрения кода, вызывающего foo - ничего не изменилось

контроллер это точка входа, если уж на то пошло.
они могут быть разные - ок, пока нет противоречий.
теперь, взяв тот же пример с business->doSomething(entity) - надо ли зашивать проверку прав внутри бизнеса - нет конечно.
один и тот же функционал в разных точках входа может требовать разный набор действий.
делаешь из веб - проверяешь права, потом дальше БЛ отрабатывает.
делаешь из консоли - проверка прав была на уровне доступа к консоли, в принципе вне твоего приложения, - а значит там уже просто БЛ отрабатывает без проверки прав.
делаешь асинхронно - ок, между поступлением в очередь и выполнением права могли измениться - очевидно чекнуть их надо.
зашив проверку в Business надо будет еще и if предусмотреть. но его ведь можно было избежать, просто композируя действия в точке входа.
другими словами - если переносишь эту композицию действий из точки входа в другое место ради переиспользования кода (ну а чо, у нас же везде логика та же самая) - придется ставить больше if, а это неправильно.

вернувшись к "не стоит получать энтити в контроллере" - ну так это точка входа в приложение, где их еще получать?

Отдельный слой, декоратор на бизнес - варианты есть.

это все if чуть на другом уровне, все еще не композиция

ну я тоже так думаю, но если не хранить ивенты внутри сущности, то других вариантов я не могу придумать.. разве что сторедж внутрь сущности пихать, через конструктор\сеттер, что тоже не очень ок, как по мне

У генератора такое предназначение - генерировать и отдваать данные. У сущности нету назначения, которое можно было бы назвать словами "таскать с собой историческое говно"

просто надо бизнес логику заворачивать в команды. Условно
new EditArticleCommand($this->getUserId(), $articleId) в контроллере будет

а где-то в кли будет команда для безусловного редактирования, хендлер которой не проверяет права, а просто редактирует

при этом все эти команды напрямую описывают те юзкейсы, который придумали ваши ПО\аналитики

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

ну если вот прямо упороться в доменные события и посмотреть в ивент сорсинг, то все что делает доменная модель - генерит события в ответ на внешние раздражители

Вот и я не могу придумать, потому и принёс сюда вопрос)

Я тоже думал об этом подходе, но возникают сложности с большим объемом данных. Т.е. в идеальном варианте должно быть два хэндлера:
EditArticle UserEditAcrticle А так же у них свои DTO
Но если входных данных будет много, то маппинг одного DTO в другое будет довольно большим по коду.
Т.е. проверка прав 1 строчка, а маппинг - 10

надо пробовать на самом деле. Да и не так плохо когда много кода. плохо когда много непонятного кода размазанног опо разным местам