# Decompose by subdomain This pattern uses a [domain-driven design (DDD)](https://en.wikipedia.org/wiki/Domain-driven_design) 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 | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | The following illustration shows how an insurance monolith can be decomposed into subdomains after it was decomposed by business capabilities. ![\[Decomposing monoliths by subdomains\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-subdomain.png) 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*.