Microservice Architecture: Decomposition Strategies, Project Types, and Common Challenges

If you are designing a large concurrent application or planning to refactor an existing legacy system, microservice architecture is often the first consideration.

Microservices build applications as a series of loosely coupled services to accelerate software development through continuous delivery and flexible deployment.

Why Decomposition Is Important

Facilitates division of labor and knowledge sharing, allowing multiple individuals or teams with specialized expertise to collaborate efficiently.

Clarifies how multiple components interact with each other.

Two Types of Projects Under Microservices

Brownfield projects – developing and deploying new software within the context of existing or legacy systems, such as converting a monolith to microservices.

Greenfield projects – building a brand‑new system from scratch without any legacy constraints.

1. Decomposition by Business Capability

One strategy for creating a microservice architecture is to split services based on business capabilities. For example, an e‑commerce platform may separate order management, inventory, payment, and shipping.

Business capabilities tend to be stable, making the underlying logic stable as well.

Development teams become cross‑functional, autonomous, and organized around delivering business value rather than technical features.

Services are loosely coupled yet highly cohesive.

2. Decomposition by Sub‑Domain (Domain‑Driven Design)

Domain‑Driven Design (DDD) defines separate domain models for each sub‑domain, each belonging to a bounded context that contains the code implementing that model.

Core – the most differentiating and valuable part of the business, such as core pricing or quotation systems.

Supporting – not a differentiator but necessary for business operations, often implemented internally or outsourced.

Generic – not specific to the business and best implemented with off‑the‑shelf solutions.

Sub‑domains are relatively stable, leading to a stable architecture.

Teams are cross‑functional, autonomous, and focused on delivering business value.

Services remain loosely coupled and cohesive.

3. Challenges When Breaking a Monolith into Microservices

Network latency – distributed systems introduce additional round‑trips between services, which can affect performance.

Data consistency – each service typically owns its own database, making cross‑service data consistency difficult.

God class – overly large, all‑knowing classes that centralize logic and become hard to maintain.

4. The Strangler Pattern

When migrating a legacy monolith to a microservice architecture, the Strangler pattern is used: new services replace specific functionalities incrementally, and once a new service is ready, the old component is retired.