What Happens After SDD (So You’re Not Guessing)
By the time you reach Strategic Domain Design, the hardest work is already done.
This is often surprising - especially to teams used to thinking of design and build as the difficult part.
This section explains what happens next, why Feedback Loops deliberately stops here, and how SDD is meant to be used.
The Common Anxiety at This Point
After completing SDD, most teams ask some version of the same question:
“Okay… now what?”
This anxiety usually comes from one of two assumptions:
- that SDD is incomplete without technical detail
- that stopping here means the system is unfinished
Both assumptions are wrong.
Strategic Domain Design Is a Design Anchor
Strategic Domain Design is not an input that gets consumed and discarded.
It is a design anchor.
Once SDD exists:
- business meaning is stabilised
- terminology is fixed
- decisions are explicit
- rules are declared
Everything that follows is constrained by this anchor.
Where Practical Domain Design Continues
Practical Domain Design consists of two inseparable parts:
- Strategic Domain Design (business description)
- Technical Domain Design (technical translation)
Feedback Loops exists to reliably produce the first part.
Once SDD is complete, Practical Domain Design continues without Feedback Loops.
That is not a gap. That is a clean handoff.
What Technical Domain Design Actually Does
Technical Domain Design takes SDD and answers a different set of questions:
- How is this business realised in this environment?
- How are rules enforced technically?
- Where do decisions live in the system?
- How are responsibilities reflected in code?
These are translation questions, not reinterpretation questions.
If TDD changes business meaning, something has gone wrong.
Why Feedback Loops Does Not Go Further
Feedback Loops stops at SDD for a reason.
Beyond this point:
- technology matters
- patterns matter
- environments differ
- constraints diverge
Trying to standardise those decisions would either:
- over-constrain teams, or
- reduce the system to vague advice
Neither is acceptable.
Multiple Implementations Are Expected
A single Strategic Domain Design can support:
- different architectures
- different languages
- different frameworks
- different operational models
This is a strength, not a weakness.
SDD captures what the business is. TDD decides how that business is implemented here.
What Changes After SDD
Once SDD is complete:
- conversations shift from meaning to tradeoffs
- disagreements become explicit design decisions
- engineers stop guessing intent
- validation becomes mechanical
The work becomes narrower and more predictable.
What Should Not Happen After SDD
After SDD, teams should not:
- rename business concepts casually
- re-litigate decisions already made
- introduce new rules without updating SDD
- bypass declared decision points
If these things happen, drift has begun.
When to Come Back to Feedback Loops
Feedback Loops is not a one-time event.
You return to it when:
- new problems appear
- assumptions are invalidated
- the business changes
- meaning becomes unstable again
SDD is durable - but not permanent.
A Reframing That Helps
Think of Feedback Loops like this:
It exists to get you to the last point where changing your mind is cheap.
Everything after SDD makes change more expensive.
That is why this boundary matters.
The Key Takeaway
If Strategic Domain Design feels complete and boring, Feedback Loops has succeeded.
From here on, the work is about execution and translation - not discovery.
Next, we will look at How to Know You’re Ready to Use the Playbook.