Very. I guess you could do BDD without DDD, but I can't see why you'd
want to. Dan and I had a long chat with Eric Evans last year, a lot of
which played into the video:
I think the phrase they came up with was that DDD provides the
vocabulary, BDD provides the grammar.
Additionally, BDD's language _is_ a ubiquitous language for the domain
of analysis (see Dan's introduction:
http://dannorth.net/introducing-bdd). If I put this list down...
Context / Given
Event / When
Outcome / Then
...can you see what he means?
> In BDD a trend seems to be to let the user stories define the tests.
We let the stakeholders drive the scenarios, and it tends to be the
QAs - perhaps in conjunction with BAs and devs - who actually write
them. The scenarios are a more detailed definition of the story (with
the code being the most detailed definition of all).
A stakeholder may not be a user. I really like Eric's example of a
cargo shipping company, where different departments think of a "cargo
shipment" in different ways - by weight and size if you're finding the
route, or by billing date and payment method if you're the accounts
department (I can't remember the exact example; go buy the book - it's
worth it!) There are other stakeholders that are sometimes forgotten;
the gatekeeper for performance targets, the security expert, the
support team (please remember that logs are a UI too!) and anyone else
who has a vested interest in the end product.
This is why BDD's outside-in is just that; from the many interfaces of
the many stakeholders - the outside shell of the BDD onion - through
any controller layers and into the domain objects.
We can sometimes derive the domain from the stories and scenarios, and
talking with the domain experts helps. We tend to use that knowledge
of the domain - and good old DDD - to help shape the way in which we
partition responsibilities further into the code base, via the magic
Does this help?
Yes. I've blogged this for you (and everyone else) - we should have
written this more explicitly somewhere before, but I can't find it!
> The second thing that is confusing me a bit is how the strong focus on
> user interaction (which is what made me interested in BDD in the first
> place) is blurring the actual testing bit, and how the code is touched
> and defined by the tests.
The user of a bit of code is another bit of code, unless it's a GUI
(or other system-level consumer interface).
Being a fan of TDD I have started to look into BDD, and I like what I
see. But there is something that is itching in the back of my head.
How well does BDD work together with Domain Driven Design (DDD)? There
is no doubt in my mind that TDD works perfect with DDD, but when it
comes to BDD it might be a slightly different story. I am not that
well into BDD yet to see how this works, so I am asking you.
My itch about BDD working together with DDD is the following:
In BDD a trend seems to be to let the user stories define the tests.
But, although user stories might work well with DDD, in DDD I feel the
core of the system is the domain model, and thus I want my tests (and
thereby my definition of the system) to focus on that model. Does not
focusing on the user stories blur the tests definitions of the domain
You might argue that BDD is about describing the tests in a readable
form for to the user. But "the user" might be different roles here.
You have the end users that provide the user stories. Another role in
DDD is the domain expert that works on the domain model. So for the
end user tests focusing on user stories is great, but for the domain
expert, shouldn't the tests focus on the domain model?
I'm really hoping you can provide me with some insight here.
- Tore Vestues
Hi All,Could you please explain a bit more about the role of stakeholders?
The way I understand it is that stakeholders define the problem domain as well as the solution domain. Is that correct?If so then do core stakeholders trump other stakeholders when their "problems" conflict with each other? For example you could say that a customer at a supermarket is a stakeholder of a new touch screen checkout system. They may say that they don't want to see any adds on the LCD screen, the CEO may say that he wants to see adds on every LCD screen! In this case does the CEO trump the customer?
If so is this conflicting with UX design, and if so how does one resolve these conflicts?Another thing. Is BDD overlooking other issues when it restricts itself to analysis of the behaviour required by the software? Should there not also be an analysis of the behaviour required by the user? For example a user might say that "the record will be saved when I click on the save button."
Then if you are only talking within the behaviour of the software and not the behaviour of the user you wouldn't be able to say "What about just pressing CTRL+S? Wouldn't that be easier and quicker given that your hands have been on the keyboard while editing the record?"
So Output Driven Development then! I guess it makes sense. It is really the output that drives the need for storage.Interestingly if the time that the output is required isn't specified then one could technically get away with storing the data in memory.Do you include operational requirements such as disk usage, network usage etc. in user stories?