| ▲ | asa400 3 days ago | |
> I might have a different take. I think microservices should each be independent such that it really doesn't matter how they end up being connected. The connections you allow or disallow are basically the main interesting thing about microservices. Arbitrarily connected services become mudpits, in my experience. > Think more actors/processes in a distributed actor/csp concurrent setup. A lot of actor systems are explicitly designed as trees, especially with regard to lifecycle management and who can call who. E.g. A1 is not considered started until its children A2 and A3 (which are independent of each other and have no knowledge of each other) are also started. > Also for many system designs, you would explicitly want a different topology, so you really shouldn't restrict yourself mentally with this advice. Sometimes restrictions like these are useful, as they lead to shared common understanding. I'd bet an architecture that designed with a restricted topology like this has a better chance of composing with newly introduced functionality over time than an architecture that allows any service to call any other[1]. Especially so if this tree-shaped architecture has some notion of "interface" services that hide all of the subservices in that branch of the tree, only exposing the public interface through one service. Reusing my previous example, this would mean that some hypothetical B branch of the tree has no knowledge of A2 and A3, and would have to access their functionality through A1. This allows you to swap out A2 and A3, or add A4 and A5, or A2-2, or whatever, and callers won't have to know or care as long as A1's interface is stable. These tree-shaped topologies can be very useful. | ||