Artikelerreichbar
Spec-Driven Development is Domain-Driven Design's Impatient Cousin
Daniel Westheide (INNOQ) am 18.03.2026 über die Frage, woher der Inhalt einer Spezifikation kommt: Der Interview-Agent eines spec-getriebenen Werkzeugs (BMAD) holt heraus, was die befragte Person an Fachwissen mitbringt, und scheitert an derselben Stelle wie Domain-Driven Design, nämlich am Zugang zu den Fachleuten. Der Unterschied liegt im Zeitpunkt: DDD hält die Fachleute während der Entwicklung verfügbar, die spec-getriebene Entwicklung verlegt die Erkundung nach vorn. Als Einsatzfeld bleibt der technische Gründer, der Fachmann, Product Owner und Entwickler in einer Person ist.
geprüft 24.09.2026
Worauf sich diese Seite beruft, wörtlich, abgerufen am 17.09.2026:
the specification layer depends completely on the quality of domain knowledge the human brings to the interview
bestätigt 24.09.2026But it cannot supply domain knowledge that isn't in the room.
bestätigt 24.09.2026DDD requires sustained, genuine collaboration between developers and domain experts to build a shared ubiquitous language and a rich domain model.
bestätigt 24.09.2026Very often, they are buffered behind proxy product owners
bestätigt 24.09.2026DDD requires domain experts to be continuously available throughout development.
bestätigt 24.09.2026A domain model that emerges through implementation and repeated collaboration will capture things no upfront interview process reliably surfaces.
bestätigt 24.09.2026There is no proxy problem. There are no organisational boundaries to cross.
bestätigt 24.09.2026can your team get genuine access to domain experts when it needs them?
bestätigt 24.09.2026
Domain-Driven Design im GlossarSpec-Driven Development im Glossar10 Vorgabe und Umfang