One of the first questions should ask for the need for distribution. There are several technical motivations behind designing distributed systems.

Typical enterprise scenarios are in essence distributed. Users or other systems that are spread across locations need to communicate with a service. This needs to happen over the network.

Another reason is scalability. If a single application reaches the point where it cannot reliably serve the overall load of clients, the business logic needs to be distributed to multiple hosts.

A similar reasoning aims toward a system's fault tolerance. Single applications represent single points of failure; if the single application is unavailable, the service won't be usable by the clients. Distributing services to multiple locations increases availability and resilience.

There are also other less technology-driven motivations. An application represents certain business responsibilities. In Domain-Driven Design language they are contained in the application's bounded context. Bounded contexts include the business concerns, logic, and data of the application and differentiate it from external concerns.

In the same way as engineers cluster code responsibilities into packages and modules, it certainly makes sense to craft contexts on a system scale as well. Coherent business logic and functionality is grouped into separate services as part of separate applications. The data and schema is also part of a bounded context. It can therefore be encapsulated into several database instances, which are owned by the corresponding distributed applications.