What is the Decompose by Subdomain pattern and how does it relate to DDD Bounded Contexts?

The Decompose by Subdomain pattern uses Eric Evans' Domain-Driven Design taxonomy to carve out service boundaries. A subdomain is a coherent slice of the problem domain. Instead of decomposing by technical layer or org chart, you model the real-world domain first, then map each subdomain to one or a small cluster of services.

DDD classifies every subdomain into one of three types, which directly influence investment and build-vs-buy decisions:

• Core subdomain — the competitive differentiator. This is where the business wins or loses. Custom-built with the best engineers. Example: personalised recommendation engine at a streaming service.
• Supporting subdomain — necessary but not differentiating. Still custom-built but simpler. Example: a notification service that sends emails and push alerts.
• Generic subdomain — commodity functionality available off-the-shelf. Buy or use open source; do not reinvent. Example: user authentication and identity management (Keycloak, Auth0).

A Bounded Context defines the explicit boundary within which a specific domain model applies. Two subdomains may share a term — "Customer" in Sales has a credit limit and purchase history; "Customer" in Support has open tickets and SLA status — but forcing one "Customer" object to serve both contexts creates a bloated model. A Bounded Context keeps these clean and separate.

The relationship between subdomains and Bounded Contexts is often 1:1, but a large core subdomain may be split into multiple Bounded Contexts for team autonomy. Each Bounded Context is a strong microservice candidate with its own data store and ubiquitous language. The Context Map documents how contexts integrate: via Shared Kernel, Customer/Supplier, Conformist, Anti-Corruption Layer, or Open Host Service relationships — each implying different levels of coupling.