Shared-nothing architectures eventually have to collaborate with other applications. The defined contracts have to be met, documented, and communicated.

This is the point, that shared-nothing architectures are only dependent on the defined contracts and responsibilities. In case of changes in the business logic the contracts are redefined and communicated. Solely the application's team is responsible for how to implement the contracts.

Interdependent systems are made up of several shared-nothing applications with well-defined interfaces. The used interfaces should be technology-agnostic to not set constraints on the used implementation.

This is the idea behind microservice architectures. Microservices consist of several interdependent applications that realize their individual business responsibilities and, combined together, solve a problem.

The name microservice doesn't necessarily say anything about the size of the application. An application should be built by a single team of developers. For organizational reasons team sizes should not grow too big. There is an often-cited notion by Amazon that the whole team should be able to survive on two pizzas.

The motivations behind distributed systems should be considered before crafting microservices. If there is no actual need to distribute a system, it should be avoided. Sticking to monolithic applications with reasonable responsibilities is to be preferred.

Usually the approach to craft microservice architectures is to slice up monolithic applications that grow too large in responsibilities, or diverged in teams and life cycles. This is comparable with refactoring approaches. Refactoring a class that grew too big into multiple delegates works well more often than trying to introduce a perfect scenario from the beginning.

In general, it's always advisable to consider the business requirements, context map of the system with their development teams and life cycles.