Как реализовать агрегатор данных с разных сервисов асинхронно ?  Например нужно с разных компаний авиа собирать данные и показывать людям в конце

Технологией, что удовлетворяет критерии заказчика и поддерживает асинхронные запросы по протоколу который использует источник.

Досылать результаты от каждого в браузер по WebSocket

Хотелось бы иметь согласованность данных, иметь возможность после перезагрузки страницы иметь актуальные данные и тп . Наверное нужно это делать где то на входном сервисе и сохранять мне кажется ... Сервисов(источников результатов) например 500. Мне нужно их каждый в контейнер обворачивать и потом получать от них данные -> скаладывать в БД результат от каждого -> на каждый такой ответ от сервиса агрегировать что ое принято от остальных и отсылать по WS.  Такое будет нормально или слишком сложно ?

PS. Заказчик и разработчик я сам и поэтому могу любые технологии использовать

Согласованность данных на чтение? Это как? А как они могут стать несогласованными?

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

Главный сервис кидает всем сообщение "егегей надо поискать под этот идентификатор запроса" и все такие ищут ищут и в ответ кидают сообщение "вот результаты" (+ могут ретраи делать) или "не удалось найти" - агрегатор просто по появлению результатов пушит данные на клиент через пулинг или через ws. Если кто-то зафэйлился ну покажешь ошибку. Не должно же это часто происходить + ретраи

Хз я может задачу не понял но хз чё сложного. Сложности обычно дальше возникают когда пользователь решение на основе возможно неактуальных данных решение принимает

Как главный сервис будет узнавать от других что они что то ототслали ? Очередь с messenger  cunsomer можно прилепить  ?

Условно у каждого эктора своя очередь и сообщения таким образом можно распределять

аля отправляем бродкаст сообщение всем сервисам - "ищите бла бла кидайте ответ в такую-то очередь" или чет такое. Воркеры сделают что им надо и ответы будут складировать в одну очередь

То есть сервис котроюый отослал бррдкаст сообщение в очередях должен быть подписан на одну эту общую очередь réponse от всех сервисоа и он будет делать уведомление по ws если нужно?

Добрый день.
Хотелось бы узнать, как можно правильно реализовать проверку товара на складе.
Когда я оформляю заказ допустим на том же dodo (для наглядности, ибо все его знают), у меня пицца может быть в составе комбо, может быть в составе какой-нибудь еще комбинации, ну и соответственно просто как пицца в корзине.
Соответственно перед созданием заказа мне нужно проверить, что "пиццы №1" не может быть больше трех в заказе (исключительно как пример), неважно в составе чего она находится - правило должно соблюдаться.
Если бы в корзине были исключительно пиццы (без дубликатов) - можно было бы легко проверить - обойти все пиццы и сверить со складом, но тут пиццы могут быть в составе комбинаций.
Как можно поступить?

Коллеги, почему многие пишут, что при сохранение эвентов не должно быть атомарности?

это сам концепт, плюс к нему конструкции Ford "Fundamentals of Software Architecture"

Тип вместо атомарности

Сохраняй все что можешь

А потом компенсируй

Попробуй рассмотреть на примере.

Ивенты сохраняются в пределах агрегата всегда атомарно. Условно говоря тебе нужно подтверждение что изменения стэйта произошли и ивенты представляют собой правду.

Другой вопрос что делать если у тебя два агрегата в одной операции. Один может успешно обновить свой стэйт а другой уже нет. И тут уже нужны компенсационные действия.

Словом я бы удостоверился что ты правильно понял суть того что там кто-то предлагает - лучше на конкретных примерах

Комбо это набор товаров, то есть если ты добавляешь комбо из 3-х товаров то в корзине условно будет 3 товара с пометкой что они дабпвлены как часть комбо.

А если так то комбо не влияют на твои ограничения и лишь могут влиять на стоимость

У меня тут скорее вопрос, куда лучше сместить ответственность за этот кейс.
Лучше из репозитория достать что-то вроде Repository.GetPizzasByCount(), а потом циклом пройтись - в доменном слое. Либо делать это внутри непосредственно агрегата?

оба варианта не очень. жирные агрегаты или логика вытекающая из оных.