Core, Supporting, and Generic Subdomain Classification
What This Concept Is
Once you have the subdomain list from concept 1, every subdomain can be classified into one of three types. The classification is not decorative. It changes how much investment the subdomain deserves, what modeling style to use, and who writes the code.
- Core subdomain -- what the company does differently from its competitors. The source of competitive advantage. Naturally complex, because if it were simple someone would have copied it already.
- Supporting subdomain -- necessary for the business but not differentiating. The business logic is simple (data entry, CRUD, glue). You cannot buy it off the shelf because it is too specific, but you do not want to invent anything either.
- Generic subdomain -- complex, but every company solves it the same way. There is a known good off-the-shelf solution (open source or SaaS). You buy, you do not build.
The three types map to three strategies:
| Type | Complexity | Differentiation | Strategy | Modeling style |
|---|---|---|---|---|
| Core | high | high | Build in-house. Invest the best engineers. Protect the model. | Domain model, possibly event-sourced |
| Supporting | low | low | Build in-house, but cheaply. Keep it simple. | Transaction script or active record |
| Generic | high | low | Buy or adopt an existing solution. Do not re-invent. | Wrap behind an ACL; do not model from scratch |
Why It Matters Here
Classification answers questions you will face constantly:
- where do the best engineers go? -> the core subdomains
- where is it safe to use a framework's built-in CRUD scaffolding? -> supporting
- where is it safe to outsource, buy SaaS, or adopt an open-source project? -> generic
- which subdomain's code deserves heavy testing, heavy review, and careful modeling? -> core
- which subdomain's code deserves a hexagonal architecture vs a transaction script? -> the former for core, the latter for supporting
Treating every subdomain the same way is the most common source of over- and under-engineering in real systems.
Concrete Example
Case: Parcel Shipping Co. subdomains classified
| Subdomain | Class | Rationale |
|---|---|---|
rating & pricing | core | Pricing accuracy, speed, and multi-carrier negotiation wins contracts. Competitors have their own rate engines. The rules are intricate (dimensional weight, surcharges, zone skips, contract overrides). |
parcel tracking | core | Our tracking UX and carrier-scan normalization are why customers stay. Quality of the unified status stream is a marketed differentiator. |
label generation | supporting | Every shipping company generates labels. Rules are finicky but not differentiating; customers compare us on price and tracking, not label PDFs. Still, no SaaS sells exactly what we need because we integrate with our proprietary pricing. |
billing & invoicing | supporting | We have specific rules (monthly aggregation, credit notes, partial-month trials) that off-the-shelf billing SaaS cannot handle cleanly, but there is no competitive advantage here. Keep the code simple. |
customer support | supporting | Case management is not how we win, but the workflow is ours (SLAs, ticket types, escalation rules) so we build it small. |
identity & access | generic | Login, SSO, password reset, session management. Dozens of battle-tested products. We use Auth0 / Okta and do not write our own. |
carrier integration | supporting | 12 bespoke adapters. Tedious, not differentiating, and also not generic (no single product covers all our carriers). Build cheaply; keep each adapter small. |
analytics / BI | generic | Dashboards, warehouse, BI tool. Snowflake + Looker. Not where we win. |
Notice that "complex" and "core" are different axes. identity & access is complex but generic (security is hard but universal). billing is simple but supporting (not generic because our rules are bespoke). Mixing these axes is where classification goes wrong.
Same axes on a different business
Case: Conference Ticketing
| Subdomain | Class | Rationale |
|---|---|---|
ticket inventory & holds | core | Preventing double-booking in a high-contention flash sale is a differentiator. |
pricing & promo codes | supporting | Rules are ours but simple. |
badge printing & on-site check-in | core | Fast offline-capable check-in is a selling point to organizers. |
payments | generic | Stripe. We do not build a payments stack. |
email / notifications | generic | Transactional-email SaaS. |
analytics for organizers | supporting | Some bespoke views, simple logic. |
Same classification, completely different answers. Classification is a function of this business, not the subdomain's name.
Common Confusion / Misconception
"Core means complicated, supporting means simple." Closer: core is complex because competitors make it complex. Supporting is supposed to be simple. Generic is often complex but so universal that reinventing it is a bad investment. The rule is: core earns complexity by giving you competitive advantage.
"Everything we built is core because we built it." No. You built supporting subdomains too -- you had no choice, there was no off-the-shelf option that matched your niche. Core is about differentiation, not about origin.
"We should pick our architecture once and apply it everywhere." You should not. A core subdomain may deserve a rich domain model and event sourcing. A supporting subdomain deserves a transaction script. Applying the same architecture everywhere is a classic source of over-engineering in supporting and under-engineering in core.
"Generic = 'we bought something.'" Not always. Generic means "the solution is well-known and shared across the industry." You could adopt open source without a vendor. The point is you should not re-invent it.
"The classification is permanent." It is not. A subdomain can evolve. Netflix's recommendation engine was core in 2010, may still be today; the storage layer under it started core, became generic as cloud databases caught up. Re-classify every year.
How To Use It
For each subdomain in your list:
- Ask: would a competitor pay to have our version of this? If yes, likely core.
- Ask: is there a reputable off-the-shelf product or open-source project that does this with minor glue? If yes, generic.
- Otherwise: supporting.
- Write the classification next to the subdomain on the wiki page.
- Derive modeling style and team allocation from the classification:
- core: domain model, senior engineers, heavy review
- supporting: transaction script, lightweight tests, junior-friendly
- generic: adopt vendor / OSS, wrap behind ACL, minimal custom code
- Re-check the classifications yearly. Evolution is normal.
Check Yourself
- Name one subdomain in a product you know that is widely mis-classified, and explain the consequence.
- Why is "we built it ourselves" not evidence that something is core?
- A team says "we are moving our recommendation engine from built-in to a vendor." What does that say about how they classify it now?
Mini Drill or Application
Extend the Parcel Shipping Co. subdomain list (or your own case from concept 1). For each subdomain:
- Write a one-line classification rationale.
- Propose a modeling style (domain model / transaction script / vendor+ACL).
- Propose a staffing level (senior-heavy / balanced / junior-friendly / vendor-managed).
- Identify at least one subdomain that might plausibly evolve to a different class in 2-3 years, and explain why.