To lift my reply up, I have expanded it here. These topics form much of the material on Day 2 of my Practical Messaging workshop next NDC Oslo 10-11 June) So the first thing to think about is the type of asynchronous conversation: * Messaging (uses a queue; transfer of control) * Eventing (uses a stream; publish-subscribe) (Replies can be either stream or queue, default to queue unless you are broadcasting). We also need to think about Provider over Producer/Consumer when thinking about the interaction. Who provides the API? The Consumer provides the API for messaging; the Producer provides the API for eventing. Concepts like In-Out, Out-Only are useful here from the old WS- Messaging specs. I use that taxonomy when I teach my workshop because it is still a useful tool. For example in In-Out we have a consumer that acts as the API provider and receives a message; it should use a queue; we have a response that probably travels back over that queue. The main issue that brings this up is causality - I need this step (taking a payment) to occur before this step (place an order). Definitely seen a few systems struggle with “event chaining” where they lose causality, particularly pernicious when a component fails (and can lead to nasty loops where work goes round and around - imagine folks keep turning up with the same order to your house). I spend time in my trying to avoid everyone reaching for a Process Manager (Saga) here. In a lot of cases I recommend what I call Turn-Taking which is essentially Pat Helland’s Activity model (components co-operate via their internal business logic).
Gregor Hohpe on the danger of believing in our abstractions - a trap that destroys architectures. It’s not only LLM’s that hallucinate.
Am I wrong in seeing similarities between Helland's Activity model and the Actor model?