Is SDD the True Parent of TDD, BDD, and DDD?

This is a provocative claim, so let me be precise about what I mean before the arguments start.

I am not claiming that SDD historically preceded TDD, BDD, or DDD — it didn’t. I am claiming something more interesting: structurally, SDD sits upstream of all three, providing the specification layer that each methodology requires but none fully defines.

What TDD, BDD, and DDD Assume

Test-Driven Development (TDD) requires that you write a failing test before you write implementation code. But this raises an immediate question: where does the test come from? What is it testing? TDD assumes you already know what to test — i.e., you have a behavioral requirement clear enough to encode as an assertion. TDD tells you how to implement against requirements. It does not tell you how to generate good requirements.

Behavior-Driven Development (BDD) extends TDD with Given-When-Then scenarios that bridge requirements and tests. It’s closer to specification — but BDD scenarios are typically written collaboratively in workshops and require significant human time. BDD gets closer to the “what,” but still depends on an upstream process to generate the scenarios worth testing.

Domain-Driven Design (DDD) focuses on modeling the business domain in code — ubiquitous language, bounded contexts, aggregates, domain events. DDD requires deep understanding of the domain requirements. It answers “how to structure the code to reflect the domain” — but it requires that the domain is already understood and specified.

All three are implementation disciplines. All three assume a specification exists or will be created. None provides a systematic, repeatable process for generating that specification.

What Specification Addresses

Spec-Driven Development addresses the phase that precedes all three: the formal articulation of what needs to be built.

An SDD requirements document, written in EARS format, produces exactly what each downstream methodology needs:

• For TDD: Each EARS requirement maps directly to one or more test cases. The “WHEN [trigger], the system SHALL [behavior]” structure is a test in natural language. The translation to code is mechanical.
• For BDD: EARS requirements are structured behavioral scenarios. They are the “Given-When-Then” formalized. BDD practitioners adopting SDD get their scenarios pre-generated.
• For DDD: Requirements written in EARS, combined with an SDD technical design phase, produce the domain model explicitly. Entities, value objects, aggregates, and domain events emerge from the design phase — named using the ubiquitous language of the domain.

The Upstream/Downstream Relationship

The relationship looks like this:

SDD (Specification)
  ├── Requirements (EARS format)
  │     └── feeds → TDD test cases
  │     └── feeds → BDD scenarios
  └── Technical Design
        └── feeds → DDD domain model

SDD provides the inputs. TDD, BDD, and DDD provide the implementation disciplines for consuming those inputs correctly.

This isn’t a theoretical observation — it’s a practical one. Teams that try to adopt TDD without good requirements write tests for the wrong behavior. Teams that try to adopt BDD without formal requirement elicitation spend entire sprint days in scenario workshops that produce the wrong scenarios anyway. Teams that try to do DDD without explicit domain modeling guidance end up with a “big ball of mud” dressed up in DDD terminology.

SDD in the AI Era

The relationship between SDD and TDD/BDD/DDD becomes even more important in AI-assisted development, for a reason that is specific to how AI works.

AI language models can execute TDD excellently — given a clear test to make pass. They can implement BDD scenarios well — given well-formed scenarios. They can implement DDD patterns well — given an explicit domain model.

The AI is excellent at the downstream implementation disciplines. It is much weaker at the upstream specification work — inferring requirements from vague prompts, choosing the right domain model, deciding which scenarios matter.

AI-SDD addresses this asymmetry directly:

• AI generates the specification (requirements, design, tasks) — human reviews and approves
• AI implements against the specification (TDD) — human validates output

The combination produces a complete development pipeline where the specification informs TDD execution. The ai-sdd framework even generates TDD-ready task lists that encode the test-first constraint into each implementation task.

A Unified View

Rather than seeing TDD, BDD, DDD, and SDD as competing methodologies, it’s more accurate to see them as complementary layers:

Layer	Methodology	Question Answered
0 — Specification	SDD	What needs to be built?
1 — Test contract	TDD/BDD	What proves it’s built correctly?
2 — Domain structure	DDD	How should the code reflect the domain?
3 — Implementation	Any	How is the code written?

SDD occupies Layer 0 — the prerequisite for all the others.

Whether you call it the “parent” of TDD, BDD, and DDD is a question of terminology. What’s not in question is this: you cannot consistently do TDD, BDD, or DDD well without the specification layer that SDD provides.

In the AI era, that specification layer is both more important and — with AI assistance — easier to produce than ever before.

---