The question I have is: wouldn't it make sense to have an hierarchical structure for mircoservices to achieve the following things:
1. Ease of understanding and being able to hide the parts of the system you don't need/want to understand: you'd only need to follow the branches of hiearchy deep enough to satisfy your necessity to know the details.
2. Less chaotic task management: when a task is created by the product manager/owner, they might not know and/or anticipate which microservices need to be changed to complete the task. With an ierarchical structure, they might as well just assign the task to, say "Authentication Service" project, but changes would have to be made to the "Geolocation service", "Personal data" and "Access control and denial" services. As a result, a task is automatically (or semi-manually) devided between the teams responsible for those sub-services.
3. Explicit coupling declaration: while each service might keep its individual team and deployment independence, hierarchy allows us to see which other services might have an issue with the this particular service after the new release is deployed.
What hierarchy actually means - is it purely logical, or does it manifest itself in requests proxying or in some other way - is not that important - it'd be up for the top-level engineering team to decide.
Thoughts?
