Message-Oriented Programming (2017)
To say that it reduces coupling is deeply misleading, IMO.<p>In order for your application to do things, certain flows must execute; A is followed by B which is followed by C for some specific functionality.<p>Without MOP, you might have A calling B, which calls C. This is straightforward to read and debug. If the interfaces between parts are complicated, they may not be easy to test - but this can be fixed.<p>With MOP, A dumps its output on a bus, and it&#x27;s picked up by B, which dumps its output on a bus, and it&#x27;s picked up by C. Now, in order to understand the composition, you need to trace the thread through the entire system, probably using string search - and not be certain you&#x27;ve got it right, because of modalities that may not be explicit.<p>It looks like the dependencies have been eliminated; but it&#x27;s a complete illusion. They&#x27;re are still there, they&#x27;re just dynamic instead of static. C still needs to follow B which needs to follow A. If any of these bits are missing, the system is broken because it won&#x27;t be functioning. And even worse, this situation won&#x27;t be found statically without extra tooling.<p>MOP and its close relative event-driven programming is effectively COMEFROM as a first-class feature. It promotes write-only programming.<p>There certainly are reasons to go down that route - for example, you need to execute a lot of unrelated side-effects based on state changes in the system - but don&#x27;t be under the illusion that it reduces coupling. The coupling is still there because the system breaks when dependencies are absent. It hides essential complexity, not just incidental complexity. Your incidental complexity burden needs to be pretty high before the pros outweigh the cons.