Я короче не силен в этом, но в целом:
1) Такие операции не про агрегаты а про какие то RAW данные
2) Если по теории агрегатов - то значит конпенсация какая то.
Если бы на другой стороне был микросервис, как мы реализовали бы такую "транзакцию" ?

Нафига усложнять там где это не нужно?
Когда у тебя агрегат уже создан и ты с ним какие то операции совершаешь то ты всё верно пишешь. Но в приложении и другие операции существуют, как та же загрузка экселя например, где "агрегат" это запись о загруженном экселе

Это класс который декларирует news.read метод в json-rpc api. При вызове которого news помечается прочитанным.

Сущность приходит сразу в __invoke от ArgumentResolver'a, коммит происходит в мидлваре.

Можно было конечно сделать коллекцию с интерфейсом, вызвать news::get(id) в методе, но нахуа?)

Аргумент резолвер примитиный, агрится на наличие атрибута Entity перед аргументом, класс берётся из typehint'a

А резолвер сущность откуда берёт, кстати? Из того упомянутого ManagerRegistry?

Или просто создаёт её как новую (вроде нет)?

да, достаётся EM по классу сущности, и get либо find если параметр nullable

get у меня искючение кидает если сущности нет

а, сразу ем. Ну если там других реализаций (не бд) не будет, то норм.

а для чего здесь явная транзакция? если flush и так все оборачивает в тарнзакцию?

Я перед тестами наполняю базу фикстурами, после каждого теста делается rollaback. Писать тесты с подменой репозиториев на in memory мне кажется чем то излишним. Может недорос ещё, хз)

Флеш оборачивает в транзакцию только то, что было вызвано до предыдущего вызова флеша. Если мы в каждый cud метод добавляем флеш, то тогда после каждого добавления будет флеш и это медленно + возможны ошибки бизнес логики. Для этого сверху ещё транзакция и нужна, если там планируется не одна операция

Репы не столь для тестов нужны, как для именно прода, после указки: "так, ребят, вот эта херня из бд выпиливается, теперь будем получать её из сервиса по ком-порту". В пхп такое редкость, кажется

Тут наверное вопрос не в пхп, а в мамкиных микросервисовписателях

Я может что-то не понял. Ну если ты вызвал flush в конце, то по времени будет всё тоже самое или нет?

Ну и это тоже. Справедливости ради, иногда выбора нет. Надо бы пойти в медицину работать. Может бы попал на такое (в целом мне такая тематика интересна)

А как ты планируешь "в конце" флеш вызывать?

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

Один агрегат в одну транзакцию, потому как с другого импорта может прийти такой же и будет дубликейт кей

foreach ($some as $another) {
    if ($what) {
        $repo->add($another);
    }
}

Если не оборачивать такое в транзакцию, то после каждого вызова add будет добавление в БД = тормоза.

С другой стороны, если в add нет flush, то не будет лишней работы UoW. Но если забыть потом заюзать внешний флешер, то данные вообще пропадут. В итоге решил, что флеш должен быть в cud методах + сверху ещё одна транзакция. Будет лишний раз гоняться UoW, но ничего не забудем и будет относительно быстро.

+ ещё может понадобиться делать $em->clear(),  если данных очень много, и вот тут уже кроме транзакции может понадобиться и внешний флешер... В итоге между этими кейсами и болтаюсь.