Microservices Decomposition Design Patterns

4 min readSep 25, 2022

This is the 4th post in a series on microservices architecture. This article is originally published at https://www.learncsdesign.com

If you are developing a large, complex application or dismantling a monolithic application, you should consider microservice architecture. A microservice architecture structures an application as a series of loosely coupled services. Microservices are designed to accelerate software development by enabling continuous delivery and deployment.

For a couple of reasons, decomposition is important:

It facilitates the division of labor and the sharing of knowledge. Using it, multiple people (or teams) with special knowledge can work productively together on an application.
It describes how the software elements interact.

Under microservices, there are two types of projects.

Brownfield projects — It refers to the development and deployment of a new software system within the context of existing or legacy systems. Therefore, converting a monolithic application to microservices would fall under this project.
Greenfield projects — This involves creating a system from scratch for a completely new environment, without any legacy code to work from. An approach used when you’re starting from scratch with no restrictions or dependencies.

Decompose by business capability pattern

In order to create a microservice architecture, one strategy is to decompose based on business capabilities. As a business, you do things to generate value. This is what a business capability is. In an eCommerce business, for example, order management, inventory management, payment, shipping, and so forth are all involved.

This pattern has the following benefits

Business capabilities are relatively stable, so the architecture is stable.
The development teams are cross-functional, autonomous, and organized around delivering business value rather than technical features.
Services are loosely coupled and cohesive.

Decompose by sub-domain pattern

The domain-driven design (DDD) approach is a way of building complex software applications that is based on the development of an object-oriented domain model. DDD defines separate domain models for each subdomain. Each subdomain belongs to a domain. Identifying sub-domains is the same process as identifying business capabilities i.e. analyzing the business and identifying expertise areas. Most likely, the end result will be subdomains that are familiar to the business. The scope of a domain model is called a bounded context in DDD. Bounded contexts include code artifacts that implement a model.

Sub-domain can be classified as follows

Core — The biggest differentiator for the business and the most valuable part of the application.
Support — Not a differentiator, but related to what the business offers. Usually implemented internally or outsourced.
Generic — Not specific to the business and are best implemented using off-the-shelf software.

This pattern has the following benefits

The sub-domains are relatively stable, so the architecture is stable.
Our development teams are cross-functional, autonomous, and focused on delivering business value rather than technical features.
Services are loosely coupled and cohesive.

Challenges while decomposing monolithic application to microservices

When decomposing monolithic applications, challenges are likely to arise.

Network latency — In a distributed system, network latency is a constant concern. You may find that a particular decomposition into services leads to a large number of round-trips between two services.
Maintaining data consistency across services — Each service would have its own database, so maintaining data consistency across services would be difficult.
God classes — God classes are objects that control too many other objects in the system, growing beyond logic to become the class that does everything. It is a class that centralizes the intelligence of a system due to its size and complexity and uses information from other classes.

Strangler Pattern

When migrating legacy monolithic applications to a microservice architecture, the Strangler pattern is used. Monolithic applications can be incrementally transformed using this pattern by replacing a particular functionality with a new service. As soon as the new service is ready, the old component is strangled and the new service is put into use, while the old component is decommissioned.