Decompose by subdomain

This pattern uses a domain-driven design (DDD) subdomain to decompose monoliths. This approach breaks down the organization’s domain model into separate subdomains that are labeled as core (a key differentiator for the business), supporting (possibly related to business but not a differentiator), or generic (not business-specific). This pattern is appropriate for existing monolithic systems that have well-defined boundaries between subdomain-related modules. This means you can decompose the monolith by repackaging existing modules as microservices but without significantly rewriting existing code. Each subdomain has a model and the scope of that model is called a bounded context; microservices are developed around this bounded context.

The following table provides the advantages and disadvantages of using this pattern.

Advantages	Disadvantages
Loosely coupled architecture provides scalability, resilience, maintainability, extensibility, location transparency, protocol independence, and time independence. Systems become more scalable and predictable.	Can create too many microservices, which makes service discovery and integration difficult. Business subdomains are difficult to identify because they require an in-depth understanding of the overall business.

The following illustration shows how an insurance monolith is decomposed into subdomains after it was decomposed by business capabilities.

The illustration shows that the “Sales” and “Marketing” services are broken down into smaller microservices. The "Purchasing" and "Claims” models are important business differentiators for "Sales," and are split into two separate microservices. "Marketing" is decomposed by using supporting business functionalities, such as "Campaigns," "Analytics," and "Reports."