Question

I like the middle-out development that is achieved with DDD. Development is driven by domain, the most solid part of application. We don’t depend on infrastructure, persistence and presentation. That sounds good. But it has no business value.

Here comes business-focused BDD with outside-in development. We have no upfront domain design (choosing entities, value objects, aggregates). We take user story, write some scenarios and implement them one-by-one. We start development from most changeable part of application – from presentation. I hate writing fragile acceptance tests. Do you?

So, if someone here have successful stories about applying DDD in BDD style, please share some with me 🙂

1. Do you write those fragile tests for presentation?
2. Do you have some design upfront before creating part of domain for user story that is implemented? Or you refactor towards DDD patterns after implementing story?

Any help will be appreciated. Thanks!

Answer 1

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.