Decomposing the Application
When approaching an existing or new application, we will need to determine where the seams are and how to decompose the application into smaller services—among the more challenging and important things to get right in a microservices architecture. We want to make sure to minimize coupling, and that we keep closely related things together. As with good component design, we strive for high cohesion and low coupling in our service design.
Coupling is the degree of interdependence, and low coupling means we have a very small number of interdependencies. This is important for maintaining an independent lifecycle for our services. To keep coupling low, we need to carefully consider how we partition the application, as well as how we integrate the services.
An important thing to consider with regard to a microservices architecture is that when we are discussing high cohesion, we generally mean functional cohesion. Cohesion is the degree by which something is related, and if the degree of cohesion is high, then it’s very closely related. Things that have very high cohesion will generally need to change together. If we are making a change to a service we want to be able to make that change in only the one service and release it. We should not have to coordinate changes and releases across multiple services. By keeping closely related things together in a service it can be much easier to accomplish this. This will also tend to reduce chattiness across the services. A key difference with a microservices architectures when compared to traditional SOA is the importance placed on functional over logical cohesion.
Refactoring Across Boundaries
Refactoring across service boundaries is extremely costly and is something we want to avoid if we can. This will likely involve planning, coordination, and possibly data migration as functionality is moved from one service to another.
We need to identify the boundaries in the application that we will use to define the individual services and their interfaces. As we mentioned previously, those boundaries should ensure closely related things are grouped together and unrelated things are someplace else. Depending on the size and complexity of the application this can be a matter of identifying the nouns and verbs used in the application and grouping them.
We can use Domain-Driven Design (DDD) concepts to help us define the boundaries within our application that we will use to break it down in to individual services. A useful concept in DDD is the bounded context. The context represents a specific responsibility of the application which can be used in decomposing and organizing the problem space. It has a very well-defined boundary which is our service interface, or API.
Bounded Context
A bounded context essentially defines a specific responsibility with an explicit boundary. The specific responsibility is defined in terms of “things” or models within some context. A bounded context also has an explicit interface which defines the interactions and models to share with another context.
When identifying bounded contexts in our domain, think about the business capabilities and terminology. Both will be used to identify and validate the bounded contexts in the domain. A deep dive into Domain-Driven Design (DDD) is out of the scope of this book, but there are a number of fantastic books in the market that cover this in great depth. I recommend “Domain-Driven Design” by Eric Evans and “Patterns, Principles, and Practices of Domain-Driven Design” by Scott Millet and Nick Tune. Defining these boundaries in a large complex domain can be challenging, especially if the domain is not well understood.
We can further partition components within a bounded context into their own services and still share a database. The partitioning can be to meet some nonfunctional requirements like scalability of the application or the need to use a different technology for a feature we need to implement. For example, we might have decided our product catalog will be a single service, and then we realized the search functionality has much different resource and scale requirements than the rest of the application. We can decide to further partition that feature into its own individual service for reasons of security, availability, management, or deployment.