Добрый день. А почему не использовали подход с шиной сообщений для стейта приложения? Слышал на нескольких докладах, что используется шина сообщений для максимального отделения приложений друг от друга.
Во-первых, в монорепозитории при использовании DI, SOLID, DDD, чистой архитектуры/feature sliced design, где все имеют доступы без сторонних библиотек к экземплярам и типам шина событий будет 5 колесом, при том что вокруг нее надо выстраивать тулинг и типизацию, что влечет дополнительные затраты на поддержку какой-нибудь библиотечки с типами Во-вторых, поток данных однонаправленый в приложениях, есть четкое разграничение роли ядра и бизнес приложения. Бизнес-приложению надо забрать из ядра важные данные (переменные окружения, авторизацию, пользователя, ролевую модель и т.д.) и работать только внутри себя. Шина тут не нужна (касаемо конкретно проекта, который я упоминал на примерах) В-третьих, мое личное мнение, что шина событий в микрофронтах не нужна, потому что без архитектурного надзора (а это 99% разработки на рынке) появятся желающие лупить события со всех сторон и превратить проект в помойку, где не понятно кто что эмитит и откуда слушает. DI великолепно закрывает проблемы стейта и не только, когда нужно перебросить что-либо, начиная от классов, заканчивая токенами. При этом, при необходимости, эти подходы можно совместить, так как шина событий и инъекция зависимостей все-таки про разное, однако, лично я не нашел на практике кейсов объединения, пока-что.
Добрый день. А почему не использовали подход с шиной сообщений для стейта приложения? Слышал на нескольких докладах, что используется шина сообщений для максимального отделения приложений друг от друга.
Во-первых, в монорепозитории при использовании DI, SOLID, DDD, чистой архитектуры/feature sliced design, где все имеют доступы без сторонних библиотек к экземплярам и типам шина событий будет 5 колесом, при том что вокруг нее надо выстраивать тулинг и типизацию, что влечет дополнительные затраты на поддержку какой-нибудь библиотечки с типами
Во-вторых, поток данных однонаправленый в приложениях, есть четкое разграничение роли ядра и бизнес приложения. Бизнес-приложению надо забрать из ядра важные данные (переменные окружения, авторизацию, пользователя, ролевую модель и т.д.) и работать только внутри себя. Шина тут не нужна (касаемо конкретно проекта, который я упоминал на примерах)
В-третьих, мое личное мнение, что шина событий в микрофронтах не нужна, потому что без архитектурного надзора (а это 99% разработки на рынке) появятся желающие лупить события со всех сторон и превратить проект в помойку, где не понятно кто что эмитит и откуда слушает. DI великолепно закрывает проблемы стейта и не только, когда нужно перебросить что-либо, начиная от классов, заканчивая токенами. При этом, при необходимости, эти подходы можно совместить, так как шина событий и инъекция зависимостей все-таки про разное, однако, лично я не нашел на практике кейсов объединения, пока-что.
@@skeev_ Спасибо за развернутый ответ.