Гайс, такой вопрос: я делаю обертку над некой очередью, дело все

реализуется в nest.js. Мысля такая, что вместо создания каждый раз новых бизнесовых Consumer и Producer будут 2 метод декоратора аля @CdConsumerTask и @CdProducer. @CdConsumerTask просто регистрирует метод бизнесового сервиса на событие из очереди так, что самому бизнесовому классу и методу ничего знать не нужно о том, что существует какая-то очередь, на которую он подписан и менять под декоратор тоже ничего не нужно. А вот с @CdProducerTask есть проблемка: сам декоратор в конечном счете делает так, что событие через глобальный Producer отправляется в очередь, но сообщение должно быть строго определенного формата с содержанием неких данных, которые может родить только бизнес сервис в рантайме. Отсюда проблема, что метод, который декорирует @CdProducer должен возвращать данные в формате, которые нужны очереди и больше этот метод кроме как для продюса сообщения в очередь не для чего нужен не будет. А это как по мне противоречит смыслу декораторов. Может у кого-то есть идеи как можно @CdProducerTask переделать? Если нужна дополнительная информация - задавайте вопросы)
Вот пример использования @CdProducer на данный момент
@CdProducer(queueName)
private updateDashboardChunk(items: ICity[], index: string, notify: boolean) {
//logic
return {
routing: dashboard_update_${index},
data: { cityCodes: items.map((city) => city.code), notify },
options: {
ttl: 240,
retry_limit: 3,
},
};
}

А чем это лучше прямого вызова метода, который отправляет в нужную очередь? Плюс я бы сказал, что декораторы должны висеть на контроллерах, а не на методах сервиса

>А чем это лучше прямого вызова метода, который отправляет в нужную очередь? Тем, что не нужно тащить логику с очередью в бизнес сервис. Таким образом отделяем логику. Непосредственно бизнес логику от какой-либо другой >Плюс я бы сказал, что декораторы должны висеть на контроллерах, а не на методах сервиса вообще, это исключительно внутренняя очередь приложения

Так а декоратор разве не в бизнес сервисе? Ты прячешь что-то за декоратором, но суть та же самая - твой сервис знает про транспорт. Знает, что он что-то кидает в брокер, так как есть декоратор, и даже как называется очередь. То, что ты вынес это знание в декоратор, не убрало связь Я потому и написал про контроллеры. Имхо, логичнее было бы декоратор там держать. Если ты переместишь декоратор в контроллер, это снимет твой вопрос?

Вообще, декоратор отделяет логику у метода, вот есть метод updateDashboard. Можно сделать отдельный контроллер на очередь в котором вызывать метод, а можно просто добавить декоратор на метод и очередь уже сама будет дергать его автоматически. Нет надобности создавать контроллер и париться с настройкой всего этого. А вот с продюсером.. Тут все завязано на том, что это должно происходить из бизнес сервиса. Но я не смог придумать, как сделать декоратор таким, чтобы логика метода была отделена от декортора и ничего про него не знала. Как думаешь, может тут лучше и проще просто внедрять продюсера в конструктор сервиса?

у меня в декоратор консюмера заложен маппер, который как раз из сообщения берет нужные поля и кладет в параметры функции. В таком случае, если меняется формат, то меняется маппер, который не относится к бл. Да, тут проблема, что декоратор завязан на определенном транспорте и нужных транспорту аргументах, но сомневаюсь, что сам транспорт когда-нибудь поменяется. Тут больше проблема именно в продюсере, а не в консюмере. А так согласен с тобой, что это не отделение больше, а модификация бл. Но такая модификация бл не вмешивается явно в сам метод и снижает когнитивную нагрузку от того, что этот метод делает с точки зрения бл. Это как делать декоратор на блокировку вызова метода с помощью редиса, да, это модификация бл, но это удобно тем, что методу ничего знать не нужно о том, что блокируется при определенных условиях и это точно не задача этого метода

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

продюсер не может лежать в контроллере, он должен быть в бизнес сервисе