How to Map a Domain: The Six Layers

The hardest part of mapping a complex domain is the blank page.

Something in front of me has grown too big to hold in my head, and I decide, finally, to draw it. I open an empty document. And then nothing happens, because there are a thousand true things I could write about this thing and no obvious reason to write one before another. So I either give up, or I produce a list that is really just the inside of my panic transcribed onto the screen, and the panic was the problem I was trying to solve.

The six layers are what I have against the blank page, six questions I have learned to ask of any domain, in roughly this order, and they turn "map this impossible thing" into six small, answerable jobs. I wrote the field itself up separately, in domain cartography, and this is the working manual for the method. None of the layers is clever on its own, and run together they turn an overwhelming pile into a map I can actually move with.

Layer 1. Primitives: what is here?

I start by naming the pieces, the objects, the entities, the roles, the systems, the accounts, the people. Not what they do yet, not how they relate, just an inventory of what is actually in the domain.

It sounds too simple to matter, and it is the step that gets skipped, and skipping it is why so much complexity feels infinite. An un-inventoried domain has no floor, and it feels like it could contain anything, because nobody has made it say what it contains. The moment I write the list, the thing stops being a fog and becomes a countable set of parts. Thirty-three repositories, not "all my projects." Four accounts, not "my money." Almost always the real number is smaller than the dread.

The way to do it is to write the flat list, fast, without organizing, and not stop to sort or judge. I am trying to hit the bottom of the pile, and the only way to know I have hit it is to keep going until I stop finding new things.

The failure mode is confusing activity with inventory and never finishing the list, so every later layer floats on top of a domain I only half-named.

Layer 2. Forces: what moves it?

A list of parts is a still photograph, and forces are what make it a system. Ask what is pushing and pulling, the incentives, the constraints, the flows, the pressures, the things that pull effort toward some parts and away from others.

Every domain has a small number of forces that explain most of the motion. Money flows toward what already works. Attention has gravity, and the things that have it get more of it. Deadlines bend everything near them. If I can name the three or four real forces in a domain, I can usually predict where it will drift next without tracking every part, because the parts are not moving on their own, the forces are.

The way to do it is to finish, for each force, the sentence "this gets more of my time or money or attention because ___." If the answer is a real pressure, that is a force. If the answer is "I am not sure," that is a part of the domain I do not actually understand yet, which is also useful to know.

The failure mode is mapping the parts and stopping, so the map is a museum that tells you what exists and nothing about what is about to happen.

Layer 3. Boundaries: what is inside, and what is not?

Now draw the edge. What is in scope, what is deliberately out, where the seams and interfaces are, what I am choosing not to hold.

This is the layer that protects me, and the one that gets treated as optional. Choosing the boundary of a map is choosing what I am responsible for. Without it the domain has no edge, which means it has no end, which means it expands to fill all the room I have and then keeps going. A boundary is what makes a map finite enough to read and a job small enough to finish.

The way to do it is to state out loud what is not on this map. "This map is my active work; archived projects are a different map." "This is my money this quarter; estate planning is elsewhere." The exclusions are as much a part of the map as the contents, and naming them is what makes the contents trustworthy.

The failure mode is no stated edge, so the map quietly grows until it is as overwhelming as the territory it was supposed to tame, and a map the size of the world is not a map.

Layer 4. Feedback: what loops?

Domains do not just sit there, they respond to themselves. Look for the cycles, the loops that reinforce and accelerate, the loops that balance and hold steady, the slow drift you only notice looking back.

The levers hide here. The repository that gets attention because it works, and works because it gets attention, is a reinforcing loop, and if I want to change its trajectory I push on the loop rather than the repo. The habit that funds the habit. The maintenance I defer that creates the fires that eat the time I needed for maintenance. Once I find the loops I stop treating symptoms, because I can finally see the thing generating them.

The way to do it is to take any two parts and ask whether one feeds the other, and whether that comes back around, then trace it until it either closes into a loop or runs off the edge of the boundary. The closed ones are the real control surface.

The failure mode is treating a loop as a one-time event, fixing the symptom and watching it regenerate, because the loop that produced it is still running untouched.

Layer 5. Governance: who decides?

Even a personal domain has governance. Ask who or what holds authority here, the rules, the ownership, the escalation path, the answer to "when this is in conflict, who decides?"

When a domain feels chaotic it is often un-governed rather than under-mapped. There is no standing answer to who gets to decide, so every decision is relitigated from scratch, every time, under load. In a team this is obvious. In a personal domain it is sneakier, because the governor is you, and "you" is not one stable thing. You on a clear morning and you at midnight are different governors with different rules, and a domain with no governance defaults to whichever one is holding the pen at the worst moment.

The way to do it is to write the decision rule for the important parts before I need it. "Archived repos do not get feature work, full stop." "No new position without bounded downside." Governance is just decisions made once, in advance and in calm, so they do not have to be made again in panic.

The failure mode is mapping everything and governing nothing, so the map describes a domain that still runs on mood.

Layer 6. Levels: what changes when you zoom?

The same domain looks like different things at different distances. Up close it is a taxonomy, a list of named parts. At mid-range it is relationships, parts wired to parts, and from far away it is dynamics, the whole thing moving as one. A finished map can move between these altitudes without changing tools.

The answer I need usually lives at a different zoom than the question I asked. "Why does this keep breaking" is asked at the level of one part and answered at the level of the loop it sits in. "What should I even be working on" is asked at ground level and answered from altitude. A cartographer stuck on one zoom is reading a street sign and wondering why it will not tell them which country they are in.

The way to do it is to describe the domain three times on purpose, at three distances, one sentence from orbit, a paragraph from mid-range, the full inventory on the ground. If I can only do one of the three, that is the zoom I am trapped at, and the trap is worth knowing about.

The failure mode is single-altitude vision, either lost in detail with no overview, or floating in abstraction with nothing concrete underneath it.

How the layers compose

I do not always need all six, and I rarely run them cleanly in order. In practice I do a rough pass over primitives and boundaries just to get a floor and an edge, then the others pull on each other. Naming a force reveals a loop, drawing a loop exposes a missing governance rule, governing a part makes me redraw the boundary. The list is a checklist I circle back through until the map stops surprising me.

Two rules hold across all of them. Every map is provisional, because the territory moves and a chart I refuse to redraw becomes a lie I am loyal to. And every map is for action, because the test of a map is never how complete or beautiful it is, only whether, looking at it, I can see the next move. If I cannot, I have made a picture of the problem and not a map.

I ran the six layers on a real, messy domain, my own sprawl, in why thirty-three repositories needed a census, which is the method with the mud still on it. This page is the manual and that one is the field.

Related reading: the frameworks, each a map of one domain.