> To attempt to define it, I would say architecture has far more to do with _where_ I draw bounded context lines than how or what tools I use to do so.
Your definition makes no sense at all. There is no distinction. Architecture specifies which components comprise the system, their interfaces, their responsibilities, and how components are expected to interact with each other. You pick certain tools because they are expected to handle certain responsibilities, because they implement certain interfaces, and because they support or enable certain types of interactions. There is no distinction.
Well I did say I'm not sure I had a clear definition..
Distinction wise, didn't you just lay out the same distinction?
And please don't get me wrong, you can have a pub/sub, rest, or event driven architecture. I would just posit that you're basing your architecture on fundamentally the wrong thing. Those sorts of things are design choices, maybe big choices but choices that are much better off being driven by the needs of the problem at hand which in any complex system is many and diverse. Your systems framework should be flexible enough to cater to whatever makes sense with the problem set.
Pushing every single problem into the same rest api, rpc, or pub/sub event system is going to end the same way.
The next time you see someone talking about some kind of architecture driven by some kind of tool replace the tool's name with "Database" and see just how stupid it sounds to even be discussing it.
> Using a database will allow for the same communications, but it’s a little more simple. Single query/result, connection pool, and transactional models are supported out of the box. Service discovery is a matter of just querying the right tables. There is an operational cost of maintaining the database, and possibly having a piece of infrastructure that impacts all services. But, all the production grade databases support clustering, but still things can go wrong and it can lock the whole system up (looking at you MyISAM).
> The primary benefit of a database driven architecture is that data is freely available. Services just provide data and don’t mandate how it is used. You still have the necessary coordination in developing a system; part a generates rows like this and part b will modify it like that. But now you can have any new service start non-destructively consuming those tables. This free flow of data allows for rapid prototyping, simple services crosscutting, intuitive monitoring and easier development.
Your definition makes no sense at all. There is no distinction. Architecture specifies which components comprise the system, their interfaces, their responsibilities, and how components are expected to interact with each other. You pick certain tools because they are expected to handle certain responsibilities, because they implement certain interfaces, and because they support or enable certain types of interactions. There is no distinction.