Core vs Supporting vs Generic Subdomains

What This Concept Is

Domain-Driven Design classifies subdomains into three kinds, by strategic importance:

• Core subdomain. The reason the system exists. The thing that, if it worked poorly, would make the capstone pointless. Core is where your effort, originality, and test coverage concentrate. It is the cluster your EventStorming (concept 04) revealed as hottest and most eventful.
• Supporting subdomain. Needed for the core to work, but not the reason for being. You must build it, but you do not need to innovate there. Good-enough code, well-tested, is right.
• Generic subdomain. A commodity capability -- authentication, logging, email delivery, rate limiting -- where "build it yourself" would be a waste. Buy, use a library, or use a managed service.

At capstone scale, the mapping is usually one core, one to three supporting, and however many generic you need. This classification is not an academic exercise: it is a time-allocation contract. You spend originality on core, craftsmanship on supporting, and integration effort on generic.

The classification also feeds directly into ADR-001 and ADR-002 (concept 12). Every build-vs-buy decision, every "we will not implement X ourselves" line, is justified by "X is a generic subdomain."

Why It Matters Here (In the Capstone)

You have six weeks. You cannot do original work everywhere. You must know where to spend the hand-crafted attention and where to plug in something prebuilt. Misidentifying the core -- for example, building "the auth system" by hand when your capstone is an inventory tracker -- is how capstones run out of time 80% in.

The second reason: the classification drives your ADRs and defense. When you choose Postgres over building-your-own-store, your ADR's "context" line is literally "persistence is a generic subdomain for this capstone." When you write your own scan-event merge logic, the ADR says "scan reconciliation is core." This is why examiners can follow your reasoning in a 5-minute defense.

The third reason: the classification is the filter for the week-1 stack decision. If auth is generic, you do not learn OAuth for the capstone -- you pick a managed auth product, or you skip auth with a shareable-URL model. If persistence is generic, you do not write a tuple store -- you use Postgres. The classification prevents week-1 rabbit holes.

Concrete Example(s) -- from a real capstone

Example A -- inventory service:

Subdomain	Type	Reasoning	Build-vs-buy decision
Scan lifecycle (receive, pick, offline queue, merge)	Core	This is the capstone's reason to exist; correctness under offline->online hand-off is the grading moment.	Build. Handwritten. Heavily tested with offline-drift drills.
Daily reconciliation view	Supporting	Needed, but computationally straightforward once the core event log exists.	Build with materialized view; no novelty.
Barcode scanning (camera -> code)	Supporting	Needed, but a solved problem.	Buy: use a WebRTC barcode library.
Persistence	Supporting	Durable storage of the event log.	Buy: Postgres.
Authentication	Generic	Not the capstone's reason to exist.	Skip for MVP (single shared device); if added, use managed auth.
Logging / metrics	Generic	Essential but undifferentiated.	Buy: cloud provider's default.

Example B -- ticketing platform:

Subdomain	Type	Reasoning	Build-vs-buy
Seat-cap enforcement (atomic decrement, no oversell)	Core	The capstone's whole value is that this invariant holds under concurrency.	Build. Tested with load scenarios.
QR issuance & verification	Supporting	Matters for the user, but mechanics are well-understood.	Build using a vetted QR library.
Email delivery of tickets	Generic	Not the capstone's point; deliverability is a hard industry problem.	Buy: managed email service.
Payment	Generic (and out-of-MVP)	Irrelevant to capstone learning goals.	Skip or stub.
Event CRUD (organizer creates/edits events)	Supporting	Needed scaffolding; not novel.	Build with straightforward REST endpoints.

Example C -- finance aggregator:

Subdomain	Type	Reasoning	Build-vs-buy
Import + idempotent dedupe	Core	Silent double-count is the failure mode the capstone prevents.	Build. Hashing + staging tables.
Categorization rules engine	Core	The user's value comes from personalized, reviewable rules.	Build, but as data (YAML) + a small evaluator.
CSV parsing	Supporting	Every bank format is slightly different; parsing is fiddly but not novel.	Buy: a CSV library + per-bank adapters.
Report rendering (markdown)	Supporting	Mechanical.	Build with a small template engine.
Storage	Supporting	SQLite suffices for one household.	Buy: SQLite.
Encryption at rest	Generic	Cryptographic primitives are the last thing a solo dev should invent.	Buy: vetted encryption library + passphrase-derived key.

Across all three: one or two cores, a handful of supporting, and as many generic as needed. Your time should roughly mirror this map -- most hand-coding in core, competent integration of supporting, minimum hassle for generic.

Common Confusion / Misconceptions

• "All my subdomains are core because I'm building everything." "I am building it" and "it is strategically core" are different claims. You will build generic things; that does not make them strategically important. Grade the subdomain, not your effort.
• "I will make auth core because auth is interesting." If auth is core, your capstone is about auth. Is it? If not, auth is generic and interesting-to-you is not a classification criterion.
• "Generic means I can ignore it." Generic means you do not innovate on it; you still must choose and integrate it responsibly. A buy-decision is still a decision, and it still deserves an ADR or a one-line note.
• "I can reclassify later." You can, but the cost is real: if you promote "auth" to core in week 4, you now have two cores and the originality budget doubles. Late promotions almost always miss the deadline. Late demotions (core -> supporting) are fine and sometimes healthy.

Signal That You Classified Wrong

If any of these are true a week into building, re-examine the classification:

• You are spending more hand-coded effort on a supporting subdomain than on the core.
• Your "core" subdomain has no novel behavior and could be replaced by a cloud service you just haven't integrated yet.
• The subdomain you are most excited about is not the one marked core. (Either promote the exciting one -- if it genuinely is what the capstone proves -- or accept that excitement is not classification.)
• You are writing tests for generic subdomains as carefully as for core.

Classification is a living judgment. Revisiting it in week 2 after the walking skeleton is often the clarifying moment: you see where the code is actually asking for more attention.

How To Use It (In Your Capstone)

1. Start from the EventStorm. For each cluster from concept 04, write one sentence: "the reason this exists is X."
2. Ask: is X the reason the whole capstone exists? If yes, core. There should be exactly one or two.
3. Else: is the capstone impossible without it? If yes, supporting.
4. Else: is it a commodity capability (auth, logs, email, payments)? If yes, generic.
5. For each supporting/generic, decide build or buy with a one-line justification. A buy that cannot be named is not a decision.
6. Record the map in the design doc (concept 10). Keep it to one small table.
7. Align time allocation. Plan weeks 2-5 so most hours go to core, then supporting, then generic. Audit weekly.

Quick Sanity Check

Before committing the classification, run three questions past it:

• If the core subdomain works perfectly and the supporting ones are clumsy, does the capstone still feel like a win? (It should.)
• If the generic subdomains were replaced overnight by trivial stubs, would the core still be demonstrable? (It should -- else those "generic" ones are actually supporting.)
• If the supporting subdomain's chosen library failed, could you swap it in a day? (It should -- else it is secretly core.)

See also (integrative)

This concept is the capstone's compressed form of strategic DDD and of the build-vs-buy discipline from decomposition-heavy prior modules.

• S7 M03 -> Core/Supporting/Generic subdomain classification -- use when you want the canonical definitions and trade-offs in full, not the capstone compression.
• S7 M03 -> Domain / subdomain / bounded context: three-level split -- use when you are confusing subdomain with bounded context. The capstone needs both straight.
• S7 M03 -> Architecture to context alignment: services per bounded context -- use when tempted to split your modular monolith into services per subdomain. Usually don't at capstone scale.
• S8 M02 -> Decomposition heuristics: capability / subdomain / noun-verb -- use when classifying a cluster that could be read as either a supporting or a generic subdomain. The heuristics disambiguate.
• S8 M02 -> Monolith-first and strangler-fig migration -- use when you are tempted to give each subdomain its own service in the capstone. Same classification, different delivery shape.

External references (curation-validated this session):

• DDD Reference -- Eric Evans (PDF) -- use when you want Evans' original vocabulary for Core/Supporting/Generic in one page.
• Strategic DDD -- Vaadin blog (Vernon-inspired) -- use when Evans' reference feels abstract; this walks a concrete example.
• Bounded Context -- Martin Fowler (bliki) -- use when you need a one-page reminder that ubiquitous language is per bounded context (which implies per subdomain in a capstone).
• Decompose by Subdomain -- microservices.io (Chris Richardson) -- use when you need to cross-check your subdomain split against the industry pattern catalog.
• Decompose by Business Capability -- microservices.io -- use when subdomain-based split feels wrong; a capability-based split sometimes fits better (e.g., "scanning" vs "reconciliation").

Check Yourself

1. Name the one core subdomain of your capstone. Why is it core and not supporting?
2. Name one generic subdomain and the build-vs-buy decision for it (with the specific product / library).
3. If you had three extra days, which subdomain would you spend them on? If the answer is not core, something is wrong.
4. For each supporting subdomain, can you name a library that already does 80% of it? If you cannot for any, re-examine whether it is really supporting.
5. If your core library failed mid-capstone, how many days would you lose swapping it? (For core: likely several -- that is acceptable. For generic: should be <1.)

Mini Drill or Application (Capstone-scoped)

• Drill 1 (15 min). From your EventStorm clusters, write the subdomain table. For each, apply the rubric and record core/supporting/generic plus build-vs-buy.
• Drill 2 (10 min). Audit your week-2-5 schedule against the classification. If equal hours go to every subdomain, you have not used the classification. Re-balance.
• Drill 3 (10 min). For each generic subdomain, name the specific product or library you will use today. No "TBD."
• Drill 4 (20 min, week 2). Walking-skeleton audit: open the repo after the skeleton is running. Count lines of hand-written code per subdomain. Does the ratio match the classification? If not, where did effort leak?
• Drill 5 (15 min). Defense-style probe: a peer asks "why did you build X yourself?" For every supporting subdomain you built, have a one-sentence answer tying to the classification.

---

Source Backbone

Capstone design applies earlier architecture and domain material. These books are the source backbone for the decisions in this module.

• Fundamentals of Software Architecture - architecture characteristics, styles, and tradeoffs.
• Learning Domain-Driven Design - domain discovery, subdomains, and bounded contexts.
• Clean Architecture - dependency direction and boundary discipline.
• API Design Patterns - contract and API decision support.