1

I'm struggling with proper design of communication between 2 separate akka microservices/bounded contexts in akka cluster.

Lets say we have 2 microservices in cluster per node.
Both microservices are based on akka.

It's clear for me that communication within particular bounded context will be handled by sending messages from actor to actor or from actor on node1 to actor on node2 (if necessary)

Q: but is it OK to use similar communication between separate akka application? e.g. boundedContext1.actor --message--> boundedContext2.actor

or it should be done via much clearer boundaries: In bc1 raise an event - publish to broker and read the event in bc2?

//Edit currently we've implemented a service registry an we're publishing events to service registry via Akka streams.

Slimer
  • 1,123
  • 2
  • 10
  • 22
  • Possible duplicate of [Communicating between two Bounded Contexts in DDD](https://stackoverflow.com/questions/16713041/communicating-between-two-bounded-contexts-in-ddd) – guillaume31 May 14 '18 at 10:55
  • Well I'm not interested in theory, I already have akka cluster based application, and I'd like to know how it should be done correctly within such architecture – Slimer May 14 '18 at 12:01
  • You're right, it's so difficult to realize that *reach out to other BC* in linked answer <=> your "send message to actor" and *event-driven* <=> your "raise event/publish to broker". So much theory. – guillaume31 May 14 '18 at 15:21

1 Answers1

2

I think there is no universal answer here.

It is like if your BCs are simple enough you can hold the BCs in one application and even in one project/library with very weak boundaries i.e. just placing them into separate namespaces and providing an API for other BCs.

But if your BCs become more complex, more independent and require its own deployment cycle then it is definitely better to construct more strong boundaries and separate microservices that communicate through message broker.

So, my answer is you should just "feel" the right way according to your particular needs. If you don't "feel" it then follow KISS principle and start with an easier way i.e. using built-in akka communication system. And if in the future your BCs will become more complex then you will have to refactor them. But this decision will be justified and it will not be an unnecessary overhead.

AlbertK
  • 11,841
  • 5
  • 40
  • 36