Честно говоря, кажется тема как-то не до конца раскрыта и хотелось бы чуть более развернутой аргументации.
Open source компоненты надо изучать, тестировать и командой поддерживать, а ESB-продукты почему-то не надо? Почему - не понятно.
Самописная шина, которую писали для конкретной организации, обычно криво написана, а вот, получается, ESB все пишутся сразу прямо и для любой организации сразу подходят. Кажется, что это не всегда так и все равно придется многое докручивать и ещё в довесок будет куча ненужного функционала.
ESB шаблон не устаревший, но реализуется теперь как набор self-hosted легковесных модулей. Чем это отличается от набора open source компонент поднятых как цепочка микросервисов не очень понятно.
Или здесь имеются ввиду какие-то вполне конкретные ESB продукты и для понимания аргументации следует сначала с ними познакомиться?
Да, вполне. На мой взгляд, достаточно здравые рекомендации без лишней назидательности. Каких-то неожиданных откровений и тайных супер приемов к счастью здесь нет. Все по делу.
Хороший совет - переписывать / проговаривать требования своим языком. Полезно, что бы выровняться в понимании с противоположной стороной.
Немного смущает, что схема повторной отправки платежа предлагает обрабатывать ошибку отправки двумя разными способами: в первом случае отправляя неповторяемый запрос сразу в базу, а во втором в DLQ. Т.е. в DLQ письмо может попасть только после второй (или более поздней) неудачной попытки. И получается, что попыток повторной отправки на одну больше, чем настроено в retry policy.
Честно говоря, кажется тема как-то не до конца раскрыта и хотелось бы чуть более развернутой аргументации.
Open source компоненты надо изучать, тестировать и командой поддерживать, а ESB-продукты почему-то не надо? Почему - не понятно.
Самописная шина, которую писали для конкретной организации, обычно криво написана, а вот, получается, ESB все пишутся сразу прямо и для любой организации сразу подходят. Кажется, что это не всегда так и все равно придется многое докручивать и ещё в довесок будет куча ненужного функционала.
ESB шаблон не устаревший, но реализуется теперь как набор self-hosted легковесных модулей. Чем это отличается от набора open source компонент поднятых как цепочка микросервисов не очень понятно.
Или здесь имеются ввиду какие-то вполне конкретные ESB продукты и для понимания аргументации следует сначала с ними познакомиться?
Да, вполне. На мой взгляд, достаточно здравые рекомендации без лишней назидательности. Каких-то неожиданных откровений и тайных супер приемов к счастью здесь нет. Все по делу.
Хороший совет - переписывать / проговаривать требования своим языком. Полезно, что бы выровняться в понимании с противоположной стороной.
А вы действительно сейчас в своей CRM клиента через функции (ну или, что там вам сейчас более подходящим кажется) описываете, а не через объекты?
Мне вот, в CRM, объекты очень даже походят.
Немного смущает, что схема повторной отправки платежа предлагает обрабатывать ошибку отправки двумя разными способами: в первом случае отправляя неповторяемый запрос сразу в базу, а во втором в DLQ. Т.е. в DLQ письмо может попасть только после второй (или более поздней) неудачной попытки. И получается, что попыток повторной отправки на одну больше, чем настроено в retry policy.