# Decompose by Subdomain

> Use DDD subdomains as your service map — core domain gets the best engineers, supporting gets good-enough.

- **Category**: Microservices
- **Subcategory**: Service Decomposition
- **Canonical URL**: https://designpattern.fyi/patterns/decompose_by_subdomain/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
For a logistics company: Route Optimization is Core (build custom, invest heavily). Driver Management is Supporting (build, but simpler). HR Payroll is Generic (use an off-the-shelf SaaS tool, don't build it).





## Trade-offs


### Advantages

- Strategic investment allocation — spend engineering effort where it counts

- DDD gives you bounded contexts for clean service interfaces

- Prevents over-engineering of non-core subdomains

- Ubiquitous language per subdomain reduces ambiguity




### Considerations & Drawbacks

- Requires experienced DDD practitioners to apply well

- Core vs Supporting boundaries are judgment calls

- Subdomains can evolve (what's Generic today may be Core tomorrow)

- Heavy upfront modeling effort







---
**Reference**: [Original Source](https://microservices.io/patterns/decomposition/decompose-by-subdomain.html)