How to Break Down Monoliths: Business‑Capability vs Subdomain Strategies for Microservices

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

Microservices build an application as a collection of loosely coupled services, enabling continuous delivery and flexible deployment to accelerate software development.

Why Decomposition Matters

Facilitates division of labor and knowledge sharing; multiple people or teams with specialized expertise can collaborate efficiently on the same application.

Clearly describes how various components interact.

Two Types of Microservice Projects

Brownfield (re‑development) projects – developing and deploying new software on top of existing or legacy systems, such as converting a monolith into microservices.

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

1. Decompose by Business Capability

One strategy is to split the system according to business capabilities. For an e‑commerce platform, typical capabilities include order management, inventory management, payment, and shipping.

Benefits of this model

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

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

Services are loosely coupled and cohesive.

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

Domain‑Driven Design (DDD) defines separate domain models for each sub‑domain. Each sub‑domain belongs to a larger domain, and the bounded context in DDD contains the code components that implement the model.

Sub‑domain categories

Core – the most differentiating part of the business, often the most valuable component (e.g., core pricing system).

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

Generic – not specific to the business; best implemented with off‑the‑shelf software.

Benefits of this model

Sub‑domain responsibilities 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 Splitting a Monolith

Network latency – distributed systems inevitably introduce latency; certain decompositions may cause excessive round‑trips between services.

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

God class – a class that accumulates too many responsibilities, becoming a centralized intelligence that is hard to manage.

4. The Strangler Pattern

When migrating a legacy monolith to a microservice architecture, the Strangler pattern is often used. New services replace specific functionalities of the old system incrementally; once a new service is ready, the corresponding legacy component is retired.

Eventually the monolith shrinks in functionality while the microservices take over the full set of capabilities.