Связь между ограниченными контекстами в кластере Акка

Question

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

Допустим, у нас есть 2 микросервиса в кластере на узел.
Оба микросервиса основаны на akka.

Для меня ясно, что общение в определенном ограниченном контексте будет обрабатываться путем отправки сообщений от актера к актеру или от актера на узле 1 на актера на узле 2 (при необходимости)

Q: но нормально ли использовать подобную связь между отдельными приложениями akka? например boundedContext1.actor - сообщение -> boundedContext2.actor

или это должно быть сделано через более четкие границы: в bc1 поднять событие - опубликовать в брокер и прочитать событие в bc2

// Редактировать в настоящее время мы внедрили реестр сервисов и публикуем события в реестр сервисов через потоки Akka.

Answer 1

Я думаю, что здесь нет универсального ответа.

Это похоже на то, что если ваши БК просты достаточно, вы можете хранить БК в одном приложении и даже в одном проекте / библиотеке с очень слабыми границами , т.е. просто помещая ихв отдельные пространства имен и предоставление API для других BC.

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

Итак, мой ответ: вы должны просто «чувствовать» правильный путь в соответствии с вашими конкретными потребностями.Если вы не «чувствуете» это, то следуйте принципу KISS и начните с более простого способа, то есть с использованием встроенной системы связи Akka.И если в будущем ваш BCs станет более сложным, вам придется их рефакторинг.Но это решение будет оправданным и не потребует лишних затрат.