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.