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 that 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 explains 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 can be 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.