Comparison of communication styles¶
Imported source page from Denys Poltorak's Architectural Metapatterns wiki. Source path: Foundations of software architecture/Arranging communication/Comparison of communication styles.md.
We have briefly discussed three approaches to communication: orchestration, choreography, and shared data. Let’s recall when it makes the most sense to use each of them.
- Orchestration is built around use cases. They are easy to program and add, no matter how complex they become. Thus, if your (sub)domain is coupled, or your understanding of it is still evolving, this is the way to go, as you will be able to change the high-level logic in any imaginable way because you express it as convenient imperative code.
- Shared data is all about… er… domain data. If you really (believe that you) know your domain, and it deals with coupled data – this is your chance. You may even add in an Orchestrator if there are use cases that involve multiple subdomains. The business logic is going to be easy to extend while changes to the data schema are sure to cause havoc.
- Choreography pays off for weakly coupled domains with a few simple use cases. It has good performance and flexibility, but lacks the expressive power of orchestration and becomes very messy as the number of tasks and components grows. It works best with independent teams and delayed processing – when users are not waiting for the final results of their actions.
There is advice from Microsoft and \[DEDS\] which makes perfect sense: use choreography for communication between bounded contexts (subdomains) \[DDD\] but revert to orchestration (or maybe shared data) inside each context. Indeed, subdomains are likely to be loosely coupled while most user requests don’t traverse subdomain boundaries – which kindles hope that their interactions are few and not time-critical. If we follow the advice, we get Cell-Based Architecture (WSO2 definition), which collects the best of two worlds: orchestration and/or shared data for strongly coupled parts and choreography between them.
By the way, you could have noticed a few odd cases:
- An Orchestrator in a control system does not run scenarios and its mode of action resembles choreography.
- A choreographed system may use a shared message format, which makes it resemble a system with shared data, even though no shared database is present.
- A shared database may be used to implement messaging for an orchestrated or choreographed system, effectively becoming a Middleware.
That likely means that our distinction between the modes of communication is a bit artificial and there exists a yet unknown deeper model to look for.