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 |
---|---|
|
|
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."