Привет ребят Хочу вникнуть в архитектуру актор веб приложений (rest бек

с базой и с внешними интеграциями типа auth0, платежными системами и прочим)
Обычно при создании большого приложения с возможностью нормально его поддерживать стараются стараются придерживаться правил “Low coupling и Hight Cohesion” и это в целом достижимо в случае обычной гексоганальной архитектуры (Model View Controller и другие), но я не понимаю как это достичь в случае акторов в случае web

То есть, попытавшись слои типа сервисов в акторы выходит такой флоу:
1. Веб фреймверк вызывает нужный роут
2. Делаем валидацию (статическую вроде типа, длины и тд)
4. Создаем канал для получения ответа от акторов (routeChannel
3. кидаем сообщение по схеме:
ServiceActor(user, routeChannel)
И ждем результат из канала с ответом
4. На уровне актор идет такая связь https://drive.google.com/file/d/1pisCKRRyUt9N94gQhlyjKO1nsY5yV4Rr/view

Если все ок, то DBWriteActor шлет в channel

Но выходит нам нужно каждый раз создавать канал в ждать сообщение от акторов

1. А что если что-то пойдет не так в UserServiceActor?
То есть, нам нужно бробрасывать в сообщение к всем акторам в флоу обработки референс, куда в конечном счета должен вернуться Ok/Error

2. А что если мы забыли в каком-то сервисе вернуть результат (или не смогли из-за неожиданной ошибки)?
Значит придется еще для каждого реквеста прикручивать скедулер, который по таймауту будет отавать клиенту респонс с ошибкой типа (Actor died)

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

Хотесь бы слышать архитектурные шаблоны в случае актор системы:
1. Web app
2. Работа с БД
3. Работа внешними интеграциями
обязательно ли фигачить что-то типа саги или в мире актор модели есть свои решение. А если есть то какие?

> 2. Делаем валидацию (статическую вроде типа, длины и тд) 4. Создаем канал для получения ответа от акторов (routeChannel 3. кидаем сообщение по схеме: ServiceActor(user, routeChannel) ужасно сложный и ненужный паттерн. Так делают только архитектурные космонавты. Акторы (процессы) и связь с ними нужны только там, где они реально нужны. При обработке веб-запросов этого как правило лучше избегать и сохранять всё в том же процессе, где и обрабатывался запрос. Но вот если запрос какой-то очень долгий, тогда уже можно выносить его в отдельный процесс, регистрировать, заводить, следить и т.п.