стороний сервис как правило имеет какой то коллбек после успешной и не успешной оплаты

Плюсую. Вебхуки есть у нормальных платежных сервисов. Дрочить каждые 20 сек - это нахера?

Используем апи платформу на проекте, точнее GraphQL часть. В целом юзабельно, но столько WTF моментов я не ловил со времен копания в престашопе.
Очень много неочевидной магии.
Очень плохая дока местами.
Очень много приходилось сидеть с Xdebug чтобы вкурить в очередной баг.

Но в целом все можно задекорировать/расширить, так что в целом юзабельная штука.

если сервис оплаты реально не дает адекватного ответа/коллбеков/и т.п., то конечно будет оптимально cli и не "каждые n секунд", как уже сказали во избежание накопления, а использовать супервизор который будет дожидаться разового выполнения и через сколько нужно секунд запускаться еще раз. Но конечно же лучше погуглить коллбеки. Помню что wayforpay, stripe, paypal и liqpay точно умею стучаться сами обратно

використовую liqpay - колбек повертається, у них в документації все прописано

я как-то пытался смотреть на апи-платформу, но так и не понял особо, зачем нужны все эти примочки.
schema.org, json-ld, HAL, Hydra - это нужные вам вещи?

Не особо. Там основной профит в куче бойлерплейта, который можно не писать, пока не припрет.

А пагинацию юзаете? Просто вроде пагинация на обычном json не работает, приходится jsonld и прочее юзать

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

Так в этом и вопрос, если ставить формат json то пагинации в ответе нет. Только с другими форматами.

Я просто костылил с response listener и форматировал  json-ld

Пагинация прописывается в аннотации для ресурса, ну и в глобальном конфиге. Не видел, чтобы она зависела от формата

Это понятно. Но json формат в response не имеет рутовых ключей. Там массив элементов сразу в корне. Поэтому некуда воткнуть пагинацию.  
ну короче примерно как то так https://github.com/api-platform/api-platform/issues/1092 . Просто не понятно, как у вас тогда работает

Ну у нас ток graphql, там другое) рест не юзаем пока

А, ок, сорян,  момент про  graphql упустил

знатоки ддд помогите, куда(в какую папочку слоя) интерфейсы адаптеров кладут?)

Каких адаптеров? По идее в инфраструктурный? А так где то было мнение что это все не про папочки.

Не про папочки и не про код, а про стратегическое проектирование, это понятно, но тут такое ддд, поэтому определится не могу, у меня сервис который должен декорировать API системы для другой внешней системы, поэтому не могу понять куда что ложить)

Вопрос
Допустимо ли в события отправлять сущности?

Кейс:
Перенёс из одного аккаунта пользователя в другой аккаунт пользователя лицензии ПО. Надо создать событие на данное действие. Есть группа подписчиков, которые его слушают.
Все они хотят знать: откуда, куда, и что.
В данном случае правильнее передавать сами готовые сущности или их ID? Некоторые слушатели события далее создадут фоновую задачу и отправят уже по шине ID.

class ExtensionAfterMoveLicenseEvent extends Event
{
        public function __construct(private User $fromUser, private User $toUser, private UserExtension $userExtension)

или всё же правильнее так

class ExtensionAfterMoveLicenseEvent extends Event
{
        public function __construct(private int $fromUserId, private int $toUserId, private int $relationId)

Не нужно отправлять сущности. Отправляйте их ид для данных которые можно взять из базы
И если нужно отправляйте стейт старый в виде элементарных единиц - строки и тп.