How You Should Be Thinking in Stage 3 (Strategic Domain Design)
Stage 3 is where most confusion happens.
Not because it is complicated - but because it feels deceptively similar to design work.
It is not.
Stage 3 is about describing the business truthfully and precisely, without solving it.
Your Job in Stage 3
Your job in Stage 3 is not to design software.
It is to:
- describe how the business actually works
- stabilise language
- expose decisions
- make rules explicit
If you leave Stage 3 with a preferred solution in mind, you have already drifted.
The Mode Shift That Trips People Up
Stages 1 and 2 are about deciding what matters.
Stage 3 is about describing what exists.
This requires a different kind of thinking:
- descriptive, not prescriptive
- precise, not clever
- grounded, not aspirational
If you are proposing improvements, you are in the wrong mode.
What You Are Actually Identifying
In Stage 3, you are identifying five kinds of things:
- Work - repeatable activities the business performs
- Roles - who is responsible for that work
- Business Records - information the business creates, changes, or relies on
- Decisions - points where judgement is required
- Rules - constraints that cannot be violated
Nothing here is technical.
If it sounds like software, step back.
Work Is Not Features
Work is not:
- screens
- buttons
- APIs
- services
Work is:
- something a person or group repeatedly does
- to move a business situation forward
If removing software would still leave the work necessary, it belongs here.
Decisions Are the Center of Gravity
Most teams underestimate decisions.
A decision exists whenever:
- multiple outcomes are possible
- someone has authority to choose
- the choice changes what happens next
If a step has no decision, it is mechanical.
Stage 3 forces you to name decisions explicitly - including who owns them.
Rules Are Not Preferences
A business rule is a constraint, not a guideline.
Rules:
- must be enforced
- must always hold true
- apply regardless of convenience
If a "rule" can be ignored when it is inconvenient, it is not a rule.
Naming rules incorrectly leads directly to fragile systems.
Language Stability Is the Goal
One of the most important outcomes of Stage 3 is stable language.
If two people use the same word to mean different things, design will fail.
Stage 3 exists to:
- pick names
- stick to them
- remove synonyms
- eliminate ambiguity
This feels pedantic.
It is foundational.
What You Are Explicitly Not Doing
In Stage 3, you are not:
- choosing technologies
- defining data schemas
- designing integrations
- optimising workflows
Those conversations are tempting.
They are also destructive at this stage.
Common Traps
Watch for these failure modes:
- using technical terms to sound precise
- inventing structure instead of extracting it
- describing how things should work
- collapsing distinct work into vague buckets
If business stakeholders cannot validate the description, it is wrong.
Signals You Are Drifting
You are probably drifting if:
- engineers dominate the conversation
- business stakeholders disengage
- diagrams appear before descriptions
- debates focus on implementation feasibility
These are signals to stop and reset.
What Good Looks Like
A good Strategic Domain Design:
- reads like a factual description
- can be understood without explanation
- matches how the business recognises itself
- exposes uncomfortable decisions
- supports multiple implementations
It should feel slightly boring.
That boredom is clarity.
The Discipline to Carry Forward
Stage 3 teaches the final core habit:
Describe the business before designing the system.
If you protect this boundary, everything downstream becomes easier.
Next, we will look at From Messy Reality to Clean Strategic Domain Design - how all of this comes together in practice.