// Domain-Driven Design · 02
Core, Supporting and Generic Subdomains
Spend design effort where the business competes; buy the rest.
How it fits together
- Broker portal uses / calls Pricing & risk (get quote)
- Broker portal uses / calls Identity provider (sign-in)
- Underwriting publishes / notifies Claims intake (PolicyIssued)
- Claims intake uses / calls Invoicing (payout)
Spot it
- Senior devs building a custom login system
- The logic that earns money gets the least care
- Every area modelled with the same rigour
It costs
Classification is a judgement call and shifts as the business strategy changes.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
Subdomains describe the problem space: the parts of what the business does. The core domain is what sets it apart and earns money (pricing for an insurer, routing for a logistics firm). Supporting subdomains are specific to the business but not a differentiator (claims intake forms). Generic subdomains are problems everyone has (identity, invoicing, email).
Bounded contexts are the solution space: the models and code you build. Ideally they line up one to one, but a legacy system often mixes several subdomains in one context, and a large core may need several contexts.
The point is where to invest. Put the best people, rich domain models and DDD tactics in the core; build supporting parts simply, often as CRUD; buy or adopt open source for generic ones, such as an identity provider (Entra ID, Auth0, Keycloak). Building a generic subdomain in-house rarely gives an edge.
Ask for it
- core domain
- supporting subdomain
- generic subdomain
- problem space vs solution space
- build vs buy
- domain distillation
Classify the subdomains of our insurance product: pricing and risk, underwriting, claims intake, broker portal, identity, invoicing, email. For each give core, supporting or generic, build or buy, the owning team and the bounded context that implements it, and flag generic parts we build in-house.