Microservices Decomposition Pattern

Decomposition is the crucial step in converting a monolithic Application to a system following Microservices Architecture.

Microservices Decomposition Pattern is a strategy used in software architecture to break down a monolithic application into smaller, more manageable microservices. This pattern aims to enhance the scalability, agility, and maintainability of the software system by dividing it into loosely coupled components, each responsible for a specific business function.

Before decomposing the microservices, there are some important things to consider.

1. Cohesiveness: Each service should do a small, related set of tasks. This means that it should focus on doing one thing well.
2. Loose Coupling: Every service should have an interface (like an API) that hides how it works inside. This makes it easier to change or replace parts without affecting other services.

Decomposition is done by following 2 strategies :

• Decompose by Business Capability
• Decompose by Sub-Domain

Decompose by Business Capability

This strategy suggests :

• Identify Business Capabilities: This means understanding what different parts of the business do.
• Create Services Based on Business Capabilities: Each service should focus on one business capability. For example, one service might handle payments while another deals with customer profiles.
• Value Generation: Each service should contribute something valuable to the business. This means it should help in making money, saving time, or improving customer satisfaction.

In simple terms, before splitting up microservices, make sure they each have a clear job to do and can work independently without causing problems for other services. Follow the pattern of breaking down by what the business needs, and ensure that each service adds value to the overall business goals.

Decompose by Sub-Domain

To use the "Decompose by Subdomain" model, we need to create services based on different parts of our business. We call these parts "subdomains." Think of a subdomain as a specific area within our business, like sales, inventory, or customer service. Each of these areas does something different and has its own set of tasks. So, we create services that match each of these subdomains. This helps us organize our software based on how our business works in real life.

To find out these different parts of our business, we need to know about two important things: DDD and Bounded Context patterns.

1. DDD (Domain-Driven Design): This helps us understand how our business works and what different areas it has. It's like making a map of our business.
2. Bounded Context: This is like drawing lines around each part of our business to show where they start and end. It helps us see where one area of our business stops and another begins.

So, to figure out our business's different parts, we need to learn about DDD and Bounded Context. They help us see the big picture and break it down into smaller, understandable pieces.