code domain

owns the authored code's information density: short exact imports, readable conditions, focused function contracts, explicit mappings, and minimal code volume.

why

one invariant: every line of authored code is findable, attributable, and cheap to change. imports, conditions, contracts, mappings, and symbol uniqueness all decide whether a reader can locate the owner of a behavior before editing it. when density drops, search degrades first and duplication follows, so the domain owns density as one concern.

when to use

owns decisions on how authored code reads, searches, or is shaped at the line and symbol level — imports, condition clarity, function signatures, type names, mappers, duplicate symbols, maintained code volume. routing, persistence, and interface questions belong to their own domains.

good and bad

bad

utils/ contains 47 files: mappings, network reads, formatting helpers,
state machines, error handlers, enum labels, and date utilities.

unrelated responsibilities hide under one unsearchable name. adding a channel name formatter, grep "Name" hits 23 files in utils/ alone; some map videos, some format UI text, some sort display names — no visible owner. so a fourth formatter is created (utils/formatChannelNameV4.ts). in production, /channel/[id] shows "My Channel" but the palette shows "my channel" because two formatters disagree on casing. a mobile refresh loads a 40kb utils bundle for 3 needed functions. unmaintainable and inconsistent.

good

mappers/channel/ contains formatters for channel data shapes.
domains/channel/ owns high-level behavior that calls mappers by name.

the folder name states one responsibility: grep mappers/, find one owner, see its casing contract. duplicates become visible because they live together. bundle impact is measurable per module. searchable, consistent, maintainable.

search pages

go to any page