Документация на соответствует реальности

Кто спорит, конечно если бы написали что нужно ещё данные к типу привести, то я бы час невтыкал где у меня баг)))

Подскажите, кто разделял шины по интерфейсу?
Суть в том, что на одной шине у меня навешены разные middleware, а на другой шине (по-умолчанию) нет.

_instanceof:
    # Все обработчики с таким интерфейсом по-умолчанию запускаются на шине по-умолчанию
    App\MessageHandler\DefaultMessageHandlerInterface:
      tags:
        - { name: messenger.message_handler, bus: messenger.bus.default }
    # Специальная шина для API c разными middleware
    App\MessageHandler\ApiMessageHandlerInterface:
      tags:
        - { name: messenger.message_handler, bus: messenger.bus.api }

Однако, php bin/console debug:messenger - показывает, что все обработчики могут быть запущены на любой шине. Не пойму как разделить их...

Буду благодарен если накидаете хороших ссылок где почитать как лучше организовать архитектуру скидок.
Требуются следующие скидки
1. Купон на любой товар продавца или конкретный товар
2. Скидка в целом пользователю
3. Скидка по условию - купил 9 товаров и 10й бесплатно и тп

В целом я понимаю что для применения скидок будет шаблон chain of responsibility

Мне больше интересно как красиво параметры передать в эту цепочку. Потому как для каждого вида скидки нужны разные параметры (сам юзер, его товары, купон и тд)

Однако передавать все в один метод как-то некомильфо. Потому как если добавится новый тип скидок - опять прикидывать доп данные которые другим видам не нужны

Но и другого способа я пока не вижу.

Буду рад советам

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

Варианты:

1. спросить у бизнеса, зачем они просят вас напилить вот это вот, если есть готовые решения\платформы (начиная от майндбокс и заканчивая менее крупными\навороченными). Иногда, может быть проще сделать интеграцию с существующим бонусным сервисом и вес бэкофис \ фронт работы с этими скидками  отдать им на откуп. Если это не галлюцинация бизнеса (давайте качать программу лояльности), то лучше использовать готовые решения, а не велосипедить, т.к. маркетолог будет эти скидки\акции тасовать как не в себя и придумывать натурально мозговыносящие условия.

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

3. если п.1 не прокатил, п2 вы уже изучили, то можно сделать свой велосипед

У вас как минимум будут сущности:
«пул промокодов» (купоны)

GUID
 Название пула промокодов
Описание пула промокодов
Настройки гашения:
— купон можно гасить многократно (да \ нет)
— гасить может только владелец (да \ нет)
Настройки генерации:
— догенерировать промокоды, если закончились
начало активности
— дата
— количество дней с момента выдачи
окончание активности
— дата
— количество дней с момента выдачи
— безсрочный купон
взаимодействие с бонусами:
— при гашении списывать бонусы в сумме купона (да \ нет)
тип промокода:
— промокод на оплату % от суммы покупки
— промокод на оплату абсолютного значения
— промокод на начисление X бонусов гасящему
— реферальный промокод на начисление Х бонусов гасящему
— реферальный промокод на начисление Х бонусов владельцу и гасящему
значение промокода:
— монетарное
— процент
реферальная программа
— количество бонусов на счёт владельца

«Промокод» (Купон):
```
GUID
GUID пула
GUID владельца (если выдан)
код (генерация по nano id)
статус:
— активен
— погашен
— удалён
— заблокирован
дата создания
дата гашения
```
— Правило применения скидки
— Критерии применения скидки (коллекция правило + услоовие (и) или)

Ко всей этой штуке вам надо будет ещё какой нить UI

Благодарю за столь развёрнутый ответ.

Интеграция со сторонними сервисами не рассматривается

Опенсорс пока не смотрел

Изучаю вопрос, собираю информацию

Какие поля вкладывать в сущность это тоже не вопрос. Тут больше вопрос красивой хорошей архитектуры

как сделать такую штуку «хорошо и правильно» мне самому интересно )))), если найдутся ещё желающие покритиковать \ посоветовать, то можно будет попробовать что нить порисовать и понять как это вот всё в сифони уложить на уровне сущностей и использования штук вроде ExpressionLanguage

почему?

Я бы вам ответил как на душе. Но скажу вежливо - не знаю, бизнись не хочет

просто вам в любом случае даже в вашу подсистему бонусов надо будет скидывать:
- заказ
- клиента
- номенклатуру

ну и дёргать ручку типа рассчитай, плюс у вас могут быть требования типа: а рассчитай как это вот прямо сейчас пока юзер на кассе стоит и в тебя это вот кинули

Сложность в том что с этим будет работать не только маркетолог. А и пользваотели. Кои сами себе свои скидки будут делать как захотят

Да. Поэтому я и прошу совета. Ибо как в цепочку это прокидывать - нарушать срп

эм, вы SaaS что ли делаете?

А-ля

Платформа для где пользователь управляет своими товарами

тогда гуглите \ смотрите что нить типа PIM (Product Information Management)