The more time I spend in software development, the more I feel like everything hinges on architecture that is flexible in the face of new understanding about the domain. Too much architecture too soon means discovery slows down. Too little later on and the system can’t evolve.

Trying to do TDD without a firm grasp of architecture patterns is like building your own straight jacket. But then later, under testing the architecture means you’ll never be truly stable.

It’s a constant balancing act between over architecting and under architecting. The answers change with the code base, and with the teams, and ultimately ideally with the richness of our understanding of the domain were operating in.

Knowing what patterns exist, why they can be useful, and how to apply them situationally are all parts of having good “taste” in software design. Which trade offs are we making and why?

All of that is software architecture. I’m spending a lot of time learning how to translate the ideas of what a product can be into essential capabilities the architecture must support. And balance not overthinking it vs building a boat that won’t float.

Beware falling into the trap of saying X is always bad. It’s always situational. Our front end is complex - because the domain is, and making the richness of interactions easy and smooth is everything.

So while I wouldn’t always reach for an event bus - in this case there are 3, each with a slightly different role to play. Websocket pushing events from the outside world. Internal bus tracking instanced stores for application state. Component bus for signaling between UI.

Taken alone, that’s too many. In context of the domain and the problem - I suspect it’s just right. Good architecture is about the domain, ease of change, and ease of implementation, probably in that order.

But we didn’t start out that way. We evolved to it over time, as our understanding of the domain increased.