Small Services
The individual services in a microservices architecture generally adhere to the single responsibility principal. The services are meant to be simple, doing one thing and doing it well. In theory if a service has more than one responsibility then we should consider breaking it up in to separate services.
Single Responsibility Principle
The single responsibility principle simply states that every class in an object-oriented programming language should be encapsulated and responsible for only a single piece of functionality.
In reality, following this principle might not make sense at times, and there can actually be good reasons to keep some of the services more coarsely grained. Some functions of the system may inherently be more tightly coupled or it may be too costly to decompose. This could be due to the need for transactional consistency, or it may just be that the features are highly cohesive and become too chatty.
The question still remains as to how big or small a service must be for it to be a properly sized microservice. There are no specific rules to measure the size of a service, but there are some general guidelines the microservices community has identified, which work well in most situations. Many start with Amazon’s principle that a service should be no bigger than one that can be developed and managed by a two-pizza team (the entire team can be fed with two pizzas). Others will use lines of code or the ability for team members to understand the entire service. Whichever metrics are used, the goal is that the individual services have a single purpose and can be easily understood and managed by small teams. As engineers, we will need to be pragmatic and consider various factors when defining service granularity and boundaries, like cohesion, coupling, communications, and data architecture.
Defining service boundaries can be one of the most challenging tasks with a microservices architecture, and doing so requires a strong understanding of the business domain. Whether decomposing an existing monolith or starting a new application, we start from the business perspective, considering the business capabilities. A good approach to identify the boundaries that separate services is using a bounded context from domain-driven design (DDD). We will cover more of the details for defining service boundaries in Chapter 3, “Microservices Design.”
Domain Driven Design (DDD)
Domain Driven Design (DDD) is a set of principles and practices to help developers define business domain models as software abstractions. We can use this process to help identify boundaries and break down our application in to individual microservices, based on business function.