Interview with Dan North on Behavior-Driven Development
40 1 8135
Dan North and Liz Keogh, the people behind Behavior-Driven Development, spoke about how BDD complements DDD with Vladimir Gitlevich at OOPSLA 2007.
Dan North: "...only Domain-Driven Design can tell me where I should or shouldn't be focusing my efforts... once I determined that some computer system might help me, I need a way of getting ... from concept to cash, from an idea of some outcome I want to a production software system making or saving me money. The way in which I get to that is Behavior-Driven Development, it's the series of conversations, interactions, ways in which I express my domain desires as functioning software... "
By anonymous 2017-09-20
I offer Dan North and myself (please excuse the rabbit in the headlights look, it was my first video) being interviewed by one of Eric Evans' colleagues on BDD and DDD.
Also you can have a sneak preview of a segment of the draft first chapter from a BDD book I'm writing (hopefully with Dan too):
As another effect, discussing the scenarios without any technical words, in business language, allowed the developers to pick up that language. They then carried that language into their codebase, implementing classes named after elements of the business domain, methods named after capabilities of those elements, and properties and variables named after their real-life properties and sub-elements.
This use of business terminology in code is referred to as the ubiquitous language in Eric Evans' book, "Domain Driven Design". Eric suggests that when developers start to code in a language which matches business stakeholders' terminology, conversations become fluid, without the need for developers (or analysts as a proxy) to translate back and forth from technical details to domain concepts. The code becomes more readable and easier for newcomers to understand. The value of each object in the system becomes more obvious, as well as the path by which it provides its value back to the user so that the user could provide value to the business.
JBehave introduced something new. Not only were the developers using business domain language; they were now using a language that the business understood to describe software terminology. Instead of words like test, acceptance test, act, arrange, assert, red bar and green bar, developers were talking about examples, scenarios, contexts, events, outcomes and behaviour.
JBehave, and BDD, had introduced a ubiquitous language for software development itself.
Hope this shows that BDD and DDD work very well together indeed. All feedback welcome, except on my dress sense.
Edit: You're right, the domain is pretty solid. That's why we focus on the more risky stuff like presentation and infrastructure, and talk about our understanding of the domain using scenarios. We can't get feedback on our understanding of the domain until we have something to get feedback with - but it doesn't stop us seeking the understanding anyway.