Bus-oriented architecture

Nat Pryce wrote interesting thoughts about bus-oriented architecture:

"I like event-based systems, especially with content based multicast. I've usually used the style in distributed systems not in a single process.

The big benefit is that you can easily change the components in the system without fiddling with the "wiring" between them.

However, there is a trade-off. The event bus hides the dependencies between your components. It looks like every component only has a dependency on the bus, but really they have connections to whichever
other components produce events they must react to or react to events that they produce. If you are not careful, the protocols between components can become an unintelligible, fragile mess.

If you design the system right, you can back out the real dependencies from your components subscription and advertisement definitions and thereby visualise the real architecture of the system with graphviz or
whatever. But usually it's up to you to expose that information at your component interfaces or even design a component system that has interfaces which can be interrogated in this way.

The other difficulty with event buses is that it's hard to compose components into larger components, unless you create a hierarchy of buses. That's doable in-process but is harder in a distributed system.

So, my steer is if components must rapidly come and go, an event bus can pay off. But if they don't, explicit wiring will be more helpful to understand the system and keep tabs on architectural cruft creeping in."


Popular posts from this blog

Computing cryptography hashes: Rust, F#, D and Scala

Upcoming F# struct tuples: are they always faster?

Composing custom error types in F#