In Domain-Driven Design, a company classifies each piece of business functionality into one of three subdomain types: core, supporting, and generic. What distinguishes a core subdomain from a generic one, and why does that distinction matter for where you invest engineering effort?
answer
- core = competitive edge
- generic = buy don't build
- supporting = necessary but not special
- invest best people in core
- classification is business-relative
basics
~20 sCore subdomains are the special sauce that makes the business win — you build these yourself and invest your best people. Generic subdomains are things every company needs (like sending email or storing files) that don't set you apart — buy or reuse them instead of building custom.
solid answer
~40 sCore subdomain = the part of the business that creates competitive advantage — unique, hard to copy, and central to why customers choose this company over rivals (e.g., a recommendation engine, a matching algorithm). Generic subdomain = solved problems every company in every industry needs — authentication, payment processing, email delivery, file storage — where there's no competitive upside to building it yourself and mature off-the-shelf/SaaS solutions exist. The distinction matters because it drives investment allocation: core subdomains get your best engineers, custom modeling, deep domain-expert collaboration, and ongoing investment, because bugs or missed opportunities there directly hurt the business. Generic subdomains should be bought, licensed, or wrapped around a commodity library/vendor — spending senior engineering time hand-rolling a generic capability is opportunity cost stolen from the core.
go deeper
Can define the three types with an example each; doesn't need to justify allocation strategy.
Can classify a given feature into one of the three categories with reasoning; understands buy-vs-build follows from classification.
Can defend a classification decision under pushback and recognizes when a 'generic-looking' capability is actually core for a specific business.
Drives the classification exercise across an entire product portfolio with stakeholders and uses it to guide org design and hiring.
## Where the buckets come from Strategic design in DDD starts with **problem-space decomposition into subdomains**, mirroring the org's real business capabilities as understood by domain experts, independent of how code or teams are eventually structured. Classification is done by asking: - does this capability **differentiate us competitively**? - is it **hard to build well**? - would competitors gain an edge if they copied it? | Type | What it is | |---|---| | **Core** subdomains | answer yes to all — it's the reason the business wins commercially | | **Supporting** subdomains | necessary for the core to function but aren't themselves a source of competitive advantage — often business-specific but replicable without much strategic risk (a custom pricing calculation, an internal reporting tool tailored to company policy) | | **Generic** subdomains | common, well-understood problems solved the same way across industries: identity/auth, payments, notifications, logging infrastructure | ## Where the money and the attention go Why classification matters: with finite engineering budget and attention, spending it on generic subdomains is waste because you're reinventing a solved wheel with no differentiation payoff, while under-investing in core starves the actual value driver. Practically, classification decides: 1. **build-vs-buy** — generic → buy/SaaS/OSS, core → build in-house, supporting → build but simply; 2. **team seniority allocation** — put your strongest engineers and closest domain-expert collaboration on core; 3. **modeling depth** — core deserves rich domain modeling with ubiquitous-language work; generic deserves a thin adapter around a vendor API. ## The cost of a wrong label Trade-offs: being wrong in either direction is costly. - **Treating a core subdomain as generic** ("the matching algorithm is basically scheduling, buy an off-the-shelf scheduler") loses competitive edge to a vendor product that can't encode your specific business rules and that competitors can also buy — you end up structurally identical to rivals. - **Treating a generic subdomain as core** (hand-rolling your own OAuth or payment gateway) burns senior engineering time, introduces security and compliance risk, and slows time-to-market compared to buying mature, audited solutions. ## What the mistake looks like a year later Failure modes in production: - **(1) Over-engineering generic subdomains** — teams build custom feature-flag systems, message queues, or auth flows because "we might need it," when a mature OSS/SaaS product exists; symptoms are maintenance burden, security patches lagging vendor cadence, and best engineers stuck maintaining plumbing instead of the differentiator. - **(2) Under-investing in core** — treating the core like a supporting concern, assigning it to junior or outsourced staff, using an anemic model with no ubiquitous-language collaboration; the symptom is the domain model becoming a dumping ground of conditionals, business rules leaking into UI or database layers, and the business unable to evolve its differentiator fast enough. - **(3) Static classification** — a subdomain that was generic at founding becomes core after a pivot (or vice versa) but nobody revisits the label, so investment stays misallocated for years. ## Putting it together Worked scenario: a ride-hailing company's real-time driver-rider matching and dynamic pricing is **core** — it directly drives which app riders choose, so the company invests heavily and puts strong engineers there. Its billing/subscription management is **supporting** — necessary, with company-specific rules (regional pricing, promotions), but not why anyone opens the app. Sending transactional emails or serving map tiles uses **generic** infrastructure — bought rather than built. Contrast this with a payments company like Stripe, for whom payment processing IS the core subdomain — its entire competitive advantage — while for a typical retailer, payment processing is generic and gets integrated via a vendor rather than built. ## The label is business-relative One more nuance: classification is relative to a specific business, not universal — authentication is generic for almost every company but would be core for an identity-as-a-service vendor whose entire product IS authentication. This is why the exercise requires talking to domain experts and business stakeholders, not engineers guessing from technical difficulty alone. In practice, teams run this classification as an explicit, revisited exercise — often a short workshop with both engineers and business stakeholders, producing a simple list of subdomains with their type — because letting classification stay implicit is exactly what causes the failure modes above; the output should also record who owns each subdomain and whether it will be bought or built.
- Is subdomain classification absolute across all companies, or relative to a specific business?Relative — authentication is generic for most companies but core for an identity vendor. Classification depends on where THIS company's competitive advantage lies, so the same technical capability can be core in one business and generic in another.
- What's a lightweight way to test whether something is actually core rather than supporting?Ask whether investing more engineering effort there measurably increases revenue, retention, or competitive moat, and whether competitors could copy it easily even seeing the code. If effort doesn't move the needle or it's trivially replicable, it isn't core.
Think of a restaurant: the core subdomain is the chef's signature recipes (why customers come back); supporting is the custom reservation workflow tailored to the restaurant's layout; generic is the point-of-sale card reader — every restaurant uses the same commodity hardware, so you rent one instead of inventing your own.
saying these in an interview costs you the question
- treats every subdomain as equally important
- can't name what the company's actual core subdomain is
- wants to build custom auth/payments 'for control' with no business justification
- assigns junior/outsourced staff to the differentiator
- classifies by technical difficulty instead of competitive value