Isn't always possible, but it's worth the constant vigilance to drive each feature towards that type of architecture.
Let's say you want to take payment and ship a product. You send a message that payment of X is needed. And... nothing happens because the component that handles that isn't listening for whatever reason. Do you wait for a message saying payment was posted? How long do you wait? What about the UI? How long does the customer wait?
It seems like a messaging system like this would require all calling components to micro-manage anything they're calling, to make sure things actually get done...
I dislike it for modelling RPC which is what you seem to be referring to.
So if I don't hear from the payment that it has been initiated, then I have to go on the basis that I can't get a payment.
But I also don't get to tell the payment how to deal with its internal activities, I don't want to know about it retrying, or working out which payment provider to use etc.
Objects arent FiniteStateMachineManagerFactories. They're actual things that your system is built to handle. If an object needs an FSM, it'll get one, just like cells have mitochondria.
I think that's part of the trick, actually. When every component of a system behaves in similar ways, it's easier to extract that behavior into re-usable patterns.
Rather than each component worrying about handling failure and micromanagement, that job is delegated to an another component, a supervisor or orchestrator. Supervision trees, automatic service discovery, and elastic resource managers all come to mind.
What payment systems don't send messages to communicate with the credit card company, or the eCheck service, or Venmo/PayPal/Apple pay? Websites and native apps alike have spinning graphics and loading bars, messages that say "please don't refresh the page while we do this". These systems are fundamentally asynchronous to begin with. By uniformly applying the practices you get consistency, in exchange for a higher low-bar of complexity (which you're likely to exceed anyway).