итектор крупной финансовой компании, и мы начинаем внедрять новую бизнес-ориентированную инфосистему в разных странах.

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

К настоящему времени я пришел на перекресток. Нашими сервисами являются, прежде всего, сервисы JSON REST, использующие Swagger для автоматизированной документации, но для того, чтобы использовать эти сервисы в наших бизнес-процессах и не допускать вложения бизнес-логики в сервисы вне домена этих сервисов, мы использовали Camunda в качестве оркестровки инструмент. И Камунда в порядке(хотя некоторые рассматривали Corezoid как альтернативу), но несколько неуклюже в том, что в противном случае является элегантным набором услуг.

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

В последние годы было движение с микросервисами к хореографии(близко к событиям) архитектура. Именно в этот момент я ищу советы от инженеров и архитекторов, которые столкнулись с аналогичными точками пересечения перекрестка.

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

И это не значит, что мы избегаем событий. Мы также реализовали события в нашей архитектуре для того, чтобы отделить многие процессы с помощью основного принципа: если вам не нужен синхронизированный ответ и вам просто нужно уведомить о том, что происходит, чтобы инициировать другой процесс, создается событие, которое может быть пойман другим процессом, который начинает выполняться. И оркестровку легче объяснить и визуализировать, ее легче настраивать и модифицировать более технически настроенными бизнес-пользователями. И я думаю, что это проще для тестирования и проверки с точки зрения бизнеса. Оркестровая архитектура, как это также(обычно) ожидает хорошего обнаружения услуг и качественной автоматизированной документации и нефункциональных требований, которые я очень ценю.

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

Но я думаю, вы видите, откуда я. Я пытаюсь рассмотреть альтернативы, не сожалея о том, что в конечном итоге управляю компанией.

Возможно, вы можете поделиться своим собственным опытом с подобной ситуацией или поделиться интересной ссылкой или двумя? Или я ищу серебряную пулю, которой еще нет?