Defining Services and Interfaces

Before we can get to work building our services, we need to define what those services are and their interfaces. When we begin decomposing the services, one of the questions that comes to mind is, how big should our services be? Deciding on the number and size of services can be a frustrating task. There are no specific rules for the most optimal size. Some combination of techniques can be used to help determine if we should consider further decomposing a service. The number of files or lines of code can provide some indication that we might want to consider breaking a service up. Another reason might be that a service is providing too many responsibilities, making it hard to reason about, test, and maintain. Team organization, which could require changes to the service partition and the team structure alike, can be a factor. Mixed service types, such as handling authentication and serving web pages, might be another good reason to further decompose a service.

An understanding of the business domain will be important here. The more we know about the capabilities and features of the application, the better we can define the services and their interfaces used to compose that application.

In the end, we want a number of small, loosely coupled services with closely related behavior located together in a service. Loosely coupled services enable us to change one service without needing to change another. It’s very important that we are able to update our services independently. We need to take some care when planning integrations between services, so that we do not inadvertently introduce coupling between the services. Accidental coupling could be caused by factors like shared code, rigid protocols, models, shared database, no versioning strategy, or exposing internal implementation details.