Поделитесь опытом как вы работаете с бизнес требованиями в разрезе их ценности для бизнеса. Ценность в плане есть набор фич, одна принесет 100к, другая 10к, другая может принесет, но не факт, другую и посчитать в $ сложно, станет проще одному аналитику анализировать данные и т.д. Как-то используете такие знания/оценки при дизайне кода, тестов?

Шарим все бизнес сценарии, которые нам в коде нужно обрабатывать. Бизнес принимает решение по каждому из сценариев (возможен отдельный митинг по обсуждению сценариев)

Потом, ещё, возможно отдельный грумминг на эстимэйты (после бреншторма вариантов)
И бизнес принимает решение на основании требований и затрат

не, мне интересно уже с точки зрения имплементации. Т.е. есть ряд фич разной ценности для бизнеса, все их нужно сделать. Будет как-то влиять их "ценность" для бизнеса на реализацию в коде, количество/проработку тестов например.
Кажется что влиять не должно, или минимально, но стал интересен чужой опыт.

тут не по фичам скорее а к чему фичи относятся и насколько они изолированы.

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

правда если сама длительность цикла поставки у тебя не меряется днями то "тут не сэкономить".

А если мне не читать нужно а ждать нужно  пока ко мне по стучится второй микррсервисов с результатом ? Тут простым sync не сделаешь  и придётся значит как я говорил поднимать 2 custom messenger в консоли для обоюдного async а?

опиши ситуацию зачем и чего ты ждешь и как это соотносится с вопросом агрегации данных для UI

Я закачал например один за другим 10 файлов текстовых  для превращения их в pdf. Конвертация  конечная будет производится на медленном сервере затем. Человек лазит по сайту и ждёт пока у него в nav bar не начнёт увеличиваться счётчик который показывает скольлк уже обработанных файлов находится у него в личном кабинете

ну тут просто - файл обработан - отправляешь об этом сообщение. Кто-то должен знать что было 10 файлов и этот кто-то будет трекать прогресс.

в целом поищи тут ADSD - там много про messaging vs request/response

Так что бы я принял сообщение мне нужно его отслеживать на сервере где была инициализирована отправка... Я вот и говорю что нужен слушальсчик запусченный как и на втором. Или делать какой то API запрос на первый но тогда мы добавляем ещё одну паралельную вещь тоьлк в другом направлении... Хотелось бы остаться тоьлк с одной технологией так ка думаю это будет как минимум надёжнее и понятливее

Cron что ли запускать и делать запросы API на command в первый сервер? :)

1. приходит запрос в апишку - запроцессь эти 10 файлов
2. запоминаем где-то что у нас есть задача такая, аля batch джоба. Говорим ей что есть вот 10 файлов
3. кидаем 10 задач в очередь. Воркеры разберутся
4. каждый воркер как закончил свой файл кидают сообщение обратно (можно через реплай, можно просто сообщение) - мол "я закончил" (или сообщить о неудаче)
5. когда все закончили, воркер который следит за стэйтом задачи может кинуть сообщение на клиент  через сокеты например. Ну или по изменению что бы прогресс трекать.

Или ты хочешь что бы все это было в пределах request/response цикла апишки? Как по мне это сильно ненадежно

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

Есть другой вариант. Сделатьj ещё один микросервис centrifugo и что бы он делал update UI делая запросы на нужный канал для каждого конкретного user

просто у тебя там вопрос был не совсем про это а скорее про "агрегацию данных для UI"

ну в целом я про него и говорил, вот 5-ый пункт.

или каждой конкретной job.