да, когда у тебя вся операция, весь юзкейс это смена имени.

доменные ивенты лучше кидать там где ты знаешь что за юзкейс выполняется. Ибо такого рода мелкие ивенты (имя поменялось) не привязанные к конкретному юзкейсу опасно выпускать наружу. Это должно оставаться строго в контексте того кто кинул ивент. А значит "нафига кидать ивент лучше дернуть метод".

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

как понять не загнал ли ты себя с такими вот доменными ивентами в угол:

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

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

всю эту логику потом хер оттестируешь и продебажишь. Сложность быстро начинает расти. А если у тебя операции "дернул метод - оно поменяло только одну сущность и только одно поле или фиксированный сэт полей" - ну там обычно вообще сложности нет и любой подход работать будет примерно одинаково

Вот у меня как раз есть кейс, когда мне надо публикать для всех юзкейсов. То есть мне именно надо ловить "изменение имени" (на самом деле не имя конечно - это просто пример) для любого юзкейса и публиковать это. И получается что сеттер - удачное место, потому что его не обойти, это поле нельзя изменить мимо сеттера.

еще есть дебильная идея делать за счет сэттеров аудит лог...

да но юзкейсы обычно выше. У меня в проекте сча много такого говна валяется которое хз даже как выпиливать.

По хорошему доменные ивенты стоит кидать наверху. Там где мы знаем что "операция заверишлась". Почему может захотеться кидать их "внизу" - когда сущности шарятся между контекстами/модулями и нет жесткой привязки сущностей к юзкейсам (по сути нет агрегатов). Или когда доменные ивенты юзаются не по назначению

Они кидаются на пост-флаш

я знаю

Согласен, агрегата в моем кейсе нет

В моем случае это кажется оверхедом, но жизнь покажет)

условно говоря у нас есть следующая схема

use case(entity, data)
 -  invoke method on entity
    - change state
- raise domain event

(замечу что где делать флаш это уже отдельная история, потому при любом варианте raise хранит ивенты в буфере и ждет post flush)

Просто в случае если весь твой юзкейс это скажем rename и сервис будет выглядеть как

$entity->rename($newName);

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

ты ж не event sourcing делаешь в конце концов

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

или где все получше с тем как юзкейсы выделялись)

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

тут еще важно понимать что если код писать на пару минут дольше то это не тот оверхэд который надо срезать.

в момент когда перестаешь говорить о нем как о сеттере.
"сеттер как антипаттерн" это большое заблуждение.

О я такое делал

все такое делали. Многие продолжают