Комментарии 3
Основная проблема такого подхода состоит в том, что внесение любого
...и дальше идет типичная мантра карго культа микросервисов...
может потребовать множественных изменений в различных подсистемах
Если этого требует функционал, он и с микросервисами потребует тех же самых изменений. Только координировать их будет в сто раз сложнее. Наивно полагать, что бизнес изменение затронет только один малюсенький сервис -- скорей всего оно как серпом проедет сразу по всей системе на всех уровнях, требуя изменений и пересборки почти всего и сразу.
будет необходимо создавать дополнительные экземпляры всего монолита, что не всегда возможно, например если внутри запущенного процесса
Фигня! Запускайте столько монолитов, сколько душе угодно -- это будет дешевле и в разы меньше по ресурсам, чем микросервисы. Причем никто не запрещает выделять разные инстансы для разных задач. Но главное -- все инстансы взаимозаменяемые.
предоставляют общий механизм вызова удаленной функции (метода), аналогичный вызовам локальных функций (методов)
...настолько же быстрый, простой, надежный, контролируемый, легко тестируемый и поддерживаемый!
Но все же остается открытым вопрос - как оптимально разделить приложение на независимые фрагменты, чтобы уменьшить неизбежные расходы по производительности при передаче данных через сеть и при этом сохранить гибкость в масштабировании и замене компонентов.
Самый демагогичный на сегодняшгий день вопрос, на который существует миллион ответов и ни одного, признанного верным. В вашем случае не будет концептуально хуже, если вы соберете обратно все *-subsystem в единый System и запакуете все в единый .jar без лишнего геморроя.
Если есть определенный функционал, который как пятое колесо в телеге, и есть реальная необходимость вынести его в отдельный сервис -- выносите, кто вам мешает? Но бездумно следовать девопс религии и пилить все, к чему только можно прикрутить API -- это попахивает идиократией. Извините за присущую резкость.
А разве в GetTransactionManager adapters не должны быть как мапа ключей к портам ?
Hexagon — гексогональная архитектура для Kotlin Backend