Microservice architecture becomes a defacto standard for enterprise applications. Organizations are adopting Microservices at a larger pace because of the benefits offered by the Microservices.
This Article is part of our Microservice series. You can find the complete list of articles here.
This article provides an overview of the Decomposition patterns in the Microservice ecosystem. One of the key challenges of a Microservices eco-system is to determine the boundaries of each service. Service decomposition patterns help us to determine the boundaries of the service.
we should define the Microservice boundaries with utmost focus. usually, this activity is carried out by the domain and technical experts. If it not done properly, you end up with undesirable characteristics like tight coupling between the services and poorly designed interfaces. One other important consideration is the SRP (Single Responsibility Principle). we must ensure all the related functionality is grouped as one service. i.e. by adopting the SRP, we can ensure that most new and changed requirements only affect a single service.
Here are the patterns that are widely used to determine the boundaries of service.
- Decompose by Business Capability
- Decompose by Subdomain
Decompose by Business Capability
Decomse by Business Capability is derived from Business Architecture Modeling. In this pattern, business capabilities influence the granularity, modularity of a service. Before delving into this pattern, let us understand more about the business capability.
A business capability defines what a business does and can do. It focuses more on “What it does” instead of “how it does”. Over a period of time, how a business achieves a specific value will change, but the value will remain the same.
Let us take an example of an e-commerce application. Below are the high-level capabilities that we may come across.
- Products management
- Cart management
- Shipping Management
- Order Management
- Payment management
- Shipping Management
- Marketing Content Management
- Notifications (Email/SMS)Management
A capability may contain additional sub-capabilities as well. For example, the above capabilities may have additional sub-capabilities.
Order management
- Order processing
- Invoice Management
Shipping Management
- Order Tracking
- Fulfillment
Marketing Content Management
- Content Management
- Campaign Management
- Discount Coupons Management
- Email/SMS Management
From the above business capabilities, we define below Microservice services
- Products Service
- Inventory Service
- Shopping Cart Service
- Ordering Service
- Shipping Service
- Payment Service
- Invoice Service
- Communication Service
- Shipment Tracking & fulfillment Service
- Content Service
- Coupon Management Service
This approach helps to ensure the business & development teams are aligned efficiently towards the goal.
Decomposition by Business Capability guides the system design according to the way the business is structured.
Decompose by Subdomain
This pattern is models the microservices around the Domain-Driven Design (DDD). DDD is a software development approach that builds around the Object-Oriented Analysis and Design (OOAD) principles and ideas. In DDD, a domain model captures knowledge about a domain in a form that can be used to solve problems within that domain. In DDD, everyone uses the same vocabulary across the teams. This is known as “Ubiquitous language.” in DDD terms.
In this pattern, we start designing the domain models using the common terminology used by the teams to define the operations. Let us consider, a ‘user’ entity in an e-commerce system. A user can be termed as ‘customer’ (Sales) ’recipient’ (shipping), ’account’ (billing), and ‘target Audience’ (marketing emails)based on the sub-domain that we are referring to.
key concepts that we must focus on the perspective of Microservices are “Sub Domains” and “Bounded Context”.
It greatly helps if we have a good understanding of Domain-Driven design when dealing with Microservices.
Domain-Driven Design defines the separate models for each subdomain. Because each entity may be called differently in each domain. Subdomains are identified using the same approach as identifying business capabilities (analyze the business and identify the different areas of expertise).
A subdomain is part of the higher-level domain and each subdomain contains its own domain model. Bounded Context refers to the boundary of a subdomain that represents the entities/domain concepts, relationships, and rules.
In this approach, we start decomposition by defining the subdomains in the domain.
The subdomains applicable for an e-commerce application are
- Products management
- Cart management
- Shipping Management
- Order Management
- Payment management
- Shipping Management
From the above business capabilities, we define below Microservice services
- Products Service
- Inventory Service
- Shopping Cart Service
- Ordering Service
- Shipping Service
- Payment Service
Decomposition by Domain guides the system design according to the analysis of the processes and information flows.
When decomposing the Microservices, we should avoid having tight coupling between the services. This can be achieved by duplicating the data in the required/dependent services.
If you are not duplicating the data it forces you to call the dependent APIs explicitly and this creates a tight coupling between the services. The issues you might encounter are performance issues due to network latency and cascading failures of the system in case of any API failure.
I prefer ‘Decomposition by Subdomain’ instead of ‘Decomposition by Business Capability’. I believe ‘Decomposition by Business Capability’ will carry forward the business inefficiencies into the application design if they are not determined before application design. whereas ‘Decomposition by Subdomain’ determine if there are any business inefficiencies in the domain.
References
If you have any suggestions/feedback on this article, please share in the comments. Thank you for reading :).
