[lll-o-lll]

Hmmm. I think this is interesting, but I’m not sure this is an “architecture”.

A workflow or “orchestrator” as defined in this article looks like another service. Unless I’m missing something, it’s a state-machine where inputs/variables are the events of other services, and where transitions trigger “commands”.

Don’t get me wrong, I see the value in pulling this logic into a central place/process in order to perform “orchestration”, I just don’t see the value in yet another framework. This is a pattern that pops up in every distributed system I’ve worked on, but it is just one of many.

In many cases, a synchronous request response end-point is all that is necessary/desired for a service tied to a customer interaction. In others, a service processing a queue backlog (with or without automatic fan-out). In others publish-subscribe seems the best fit. In others, a more complex state-machine managing several different events, transitions, and outputs.

Can you model everything as a state-machine? Yes. Should you? I would argue that you want a range of tools in the toolbox.

[karmakaze]

This 'orchestrator' pattern merely re-introduces tight-coupling via a one-way async interface. The producer writes commands destined for the executor of the command. It's basically async RPC with transparent host lookup and no return values.

I'm not saying it doesn't have its uses, but be wary of tight coupling. If you see development patterns like first updating the consumer to enable a change to a command, then releasing the upstream change to use the new capability, you'll know that you're not working with a decoupled system. Another likely red-flag is never documenting payload structures, so that behaviour is fully implementation-defined async-spaghetti.