Microservices Decomposition Design Patterns

For a couple of reasons, decomposition is important:

  1. 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.
  2. It describes how the software elements interact.

Under microservices, there are two types of projects.

  1. 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.
  2. 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

This pattern has the following benefits

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

Decompose by sub-domain pattern

Sub-domain can be classified as follows

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

This pattern has the following benefits

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

Challenges while decomposing monolithic application to microservices

  1. 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.
  2. Maintaining data consistency across services — Each service would have its own database, so maintaining data consistency across services would be difficult.
  3. 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

References

--

--

--

“Walking on water and developing software from a specification are easy if both are frozen”

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How Data Oriented Companies like Facebook stores and process data ?

Algorithms and Data Structures for beginners using C# (part 1)

Data Structures: A Summary

sTokens, NFTs mirroring DEV staking

Introduction to Arduino

Ordering pizza with Alexa skills, AWS lambda and Java

Five Factors to Consider when Choosing Hydraulic Fittings

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Neeraj Kushwaha

Neeraj Kushwaha

“Walking on water and developing software from a specification are easy if both are frozen”

More from Medium

Microservices Service Discovery Design Patterns

Domain-driven design practice — Modeling payments system

How to design sales inventory Microservice based on event-driven architecture?

Microservices Shared Libraries — Design and Best Practices