THANK YOU to the person who had asked the original question on this!
I'd like to learn from a concrete example (at least from a UML interface/sequence diagram-level) which distills the fundamental design concepts for how to design one respectable Akka Microservice using a "Bounded-Context"; and which communicates with one other Microservice using a (different) "Bounded-Context". Would be THRILLED if someone could please share a reliable Blog resource on this topic that speaks in: "I-need-to-build-this-so-talk-to-me-with-concrete-details".
POSSIBLE EXAMPLES:
From the familiar online shopping domain
- a Customer Order Service talking to a Seller Fulfillment Service
From the familiar stock purchase domain:
- a Client Stock Buy Order Service talking to a Broker Stock Fulfillment Service
QUESTIONS (i.e. do Old-School Design techniques still apply, and if not; how to evolve, exactly?):
1) What if there's a connection failure; and a message gets dropped? How do you: (a) Detect that case in a performant way? (b) Recover from that in a performant way?
OLD-SCHOOL: Buy Order gets dropped -- So Buy Service waits for an ACKnowledge from Fulfillment service; then retries after a time interval? Then shows error message to User after X retries?
2) What if the Order Service changes its Order Format? How do you: (a) Have the Fulfillment Service understand this new version and not choke on the new format?
OLD-SCHOOL: Put Version Numbers within the message format between Services; and spin up new Fulfillment instance with dedicated Case-pattern for servicing only the new message version Type to avoid extended case-pattern-matching logic or inefficient message filters?
3) What if you have a Buy Program Sequence you need to execute -- i.e. BUY Lightbend, then BUY FunctionalDemocracy, but only if the first buy transaction completed?
OLD-SCHOOL: Buy Service has Actor accumulating Buy Program Execution Progress; and waits for Fulfillment Service ACKnowledge before going to the next step?
And, does this Use Case necessarily eliminate the NEW SCHOOL Optimistic State Updates in the Client's UI; therefore Client UI (necessarily) experiences a somewhat non-responsive WAIT time?