Skip to content

Domain Map

Artifact — instantiates Knowledge Map Navigation

A one-glance overview that draws the outer edge of a whole field, divides it into major regions, and marks where a newcomer can sensibly enter.

A Domain Map is the top-level orientation view of a subject: it draws the outer boundary of what the field covers (and, by implication, what it doesn't), carves the interior into a handful of major regions, and marks a few sensible places to enter. Its defining trait is altitude — it deliberately sacrifices detail for the big picture, answering "what is this whole territory, and where am I in it?" rather than "what exactly is in this corner?" Where a concept map or ontology drills into precise entities and relations, a Domain Map stays zoomed out so a newcomer can grasp the extent and shape of a field in a single glance before diving anywhere. It is the map you hand someone on day one so they stop mistaking the corner they landed in for the whole country.

Example

A payments company keeps losing new engineers to weeks of disorientation — they land in one microservice and have no idea how it relates to the rest. An architect draws a Domain Map: a single page bounding the whole payments domain and dividing it into regions — authorization, clearing & settlement, ledger, fraud & risk, disputes — with a one-line "what happens here" under each and three marked entry points ("new to payments generally, start here; joining the ledger team, start here; debugging a failed charge, start here"). The map settles no argument and stores no detail. What it does is give a newcomer, on their first morning, the shape of the territory and a defensible place to begin — so their first questions are "how does authorization hand off to settlement?" instead of "wait, what even is settlement?" Following the old caution that the map is not the territory,[1] the architect keeps it deliberately coarse: enough to orient, not enough to be mistaken for the system itself.

How it works

  • Bound the scope. Draw the field's outer edge first — what is in, what is out — so the map has a defined extent and readers know what it does not claim to cover.
  • Partition into regions. Divide the interior into a small number of major areas (few enough to hold in one glance) and label each with its essence, not its details.
  • Mark entry points. Identify the handful of sensible places to start, keyed to who the newcomer is and what brought them, so the overview doubles as a first step.
  • Hold altitude. Resist the pull to add detail; the value is entirely in staying zoomed out.

What distinguishes it from its siblings is that it maps territory and extent, not entities, relations, sequences, or gaps — it is the frame the others sit inside.

Tuning parameters

  • Altitude — higher (fewer, broader regions) orients faster but risks being too vague to act on; lower adds useful detail but slides toward a diagram that no longer fits on one page.
  • Scope boundary placement — a tight boundary makes the field crisp but may exclude adjacent territory the reader will hit immediately; a generous boundary is inclusive but blurs what the field actually is.
  • Region count — five-to-nine regions stay graspable; beyond that the overview stops being an overview.
  • Entry-point framing — organized by audience (who you are) versus by task (what you came to do); the right choice depends on why people arrive.

When it helps, and when it misleads

Its strength is fast orientation: it gives a newcomer the shape and edges of an unfamiliar field before they can possibly hold the detail, and it gives everyone a shared reference for "which part of the domain are we talking about." It is the natural first artifact for onboarding, scoping, and cross-team conversations.

Its failure mode is being mistaken for the territory. A Domain Map's regions are a convenient carving, not a natural fact — real work spills across the boundaries it draws, and someone who treats the map as complete will be blindsided by everything it abstracted away. The classic misuse is drawing the regions to match the org chart rather than the domain, so the map quietly encodes how the company is structured instead of how the subject actually works. The discipline is to label the map as an overview, keep it coarse on purpose, and redraw it when the field (not the reporting lines) shifts.

How it implements the components

A Domain Map fills the archetype's scope-and-orientation slots:

  • knowledge_domain_scope — its first move is bounding the field's extent: what is inside, what is outside.
  • cluster_boundary — it partitions the interior into a small set of named major regions.
  • entry_point — it marks the sensible places for a newcomer to begin, keyed to who they are or why they came.

It does not carry the internal entities and relations (concept_node, relation_edge — that's Concept Map), sequence a learner through the field (navigation_path, difficulty_gradient — that's Learning Path Guide), or track the field's open questions (gap_marker, confidence_or_evidence_note — that's Research Landscape Map).

Notes

A Domain Map maps a field's conceptual territory; its close sibling the Research Landscape Map maps a live research field's frontier (open questions, evidence strength). The Domain Map is for a stable subject you need to orient within; the landscape map is for a moving field you need to place bets in.

References

[1] "The map is not the territory" — Alfred Korzybski's caution that a representation is a selective abstraction of what it depicts, never a substitute for it; central to why a Domain Map must be read as an overview, not the thing itself. ↩