Запрос от фронта до конечных сервисов можно прошить corelation_id, operation_id, для анализа этого выше крыши. Проблема не в том. При использовании асинхронной в своей природе среды, как синхронной, рождает ворох проблем - отсутствие понимания готовности получателя принять запрос, реакция на таймаут запроса в целом, при таймауте в сервисе внутри цепочки. Перевод асинхрона в синхрон очень неоднозначная штука.
Не понятно что хотели сказать, рассказать в этой статье. Да существует доменоореинтированный подход, да кафку можно использовать для обмена сообщениями между сервисами. Материал не несет никакой конкретики. Можно было сделать статью болле всеобъемлющей, написав можно сделать что угодно и чем угодно, разделяя контекст и используя доменоорентированное проектирование. Лучше поделитесь что интерсного жизнеспособного вы почерпнули из ссылок на которые отправляете.
Как раз у меня есть проект в такой конфигурации и с дроблением на множество доменов, с разделением на слои и как результат каскадным прохождением цепочки событий (запросов) через сервисы.
Точно скажу - для обработки сообщений по некоторой цепочке в одну сторону это хорошо, для общения доменных сервисов 'запрос-ответ' то еще...
Начинать писать на этом надо было несколько лет назад
Если выходят и никто не жалуются, то думаю рабочие )
А как они не знают минимум и работают, еще и многие подолгу. Может это не минимум тогда?
Запрос от фронта до конечных сервисов можно прошить corelation_id, operation_id, для анализа этого выше крыши. Проблема не в том. При использовании асинхронной в своей природе среды, как синхронной, рождает ворох проблем - отсутствие понимания готовности получателя принять запрос, реакция на таймаут запроса в целом, при таймауте в сервисе внутри цепочки. Перевод асинхрона в синхрон очень неоднозначная штука.
Не понятно что хотели сказать, рассказать в этой статье. Да существует доменоореинтированный подход, да кафку можно использовать для обмена сообщениями между сервисами. Материал не несет никакой конкретики. Можно было сделать статью болле всеобъемлющей, написав можно сделать что угодно и чем угодно, разделяя контекст и используя доменоорентированное проектирование. Лучше поделитесь что интерсного жизнеспособного вы почерпнули из ссылок на которые отправляете.
Как раз у меня есть проект в такой конфигурации и с дроблением на множество доменов, с разделением на слои и как результат каскадным прохождением цепочки событий (запросов) через сервисы.
Точно скажу - для обработки сообщений по некоторой цепочке в одну сторону это хорошо, для общения доменных сервисов 'запрос-ответ' то еще...