BDD and DDD together

[Tore Vestues]

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
model?

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

[Olof Bjarnason]

2008/12/9 Tore Vestues <tore.v...@gmail.com>

What is the difference between an end user of the system and a domain expert?

[Greg Young]

Just to be clear ...

having a "shared language" and an "ubiquitous language" is fine in my
eyes as they are in different contexts.

Cheers,

Greg

On Tue, Dec 9, 2008 at 12:47 PM, Greg Young <gregor...@gmail.com> wrote:
> I looked at this a while ago.
>
> I found that many of the tests in terms of my stories were not
> actually in my ubiquitous language but were instead in what I deemed
> the "shared language".
>
> To be clear, my ubiquitous language is often quite complex and
> requires a true SME in order to comprehend it's meaning. Often my
> users in my stories are not SMEs and as such have a simplified version
> of the system (as if viewed through a facade). This process happens at
> all levels though the ones closest to the domain tend to be the ones
> closest to the ubiquitous language.
>
> I had written a post about this some time ago
> http://codebetter.com/blogs/gregyoung/archive/2007/10/16/bdd-and-the-shared-language.aspx
>
> Cheers,
>
> Greg

> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>



--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

[Pat Maddox]

Lots, usually. Most of the time, end users are only interested in
getting some stuff done, and don't have intimate knowledge of the
domain.

Pat

[Tore Vestues]

It might be the same person, but the roles can differ.

The end user is actually using the system, and focuses more on the
workflow, considering the system as a black box. The domain expert is
defining the core of that black box, the domain model.

To me it seems that BDD has a focus on letting the tests define the
system through "the workflow" (the user stories), while in DDD we
might want the tests to define the domain model directly.

.Tore


On Dec 9, 9:55 pm, "Olof Bjarnason" <olof.bjarna...@gmail.com> wrote:
> 2008/12/9 Tore Vestues <tore.vest...@gmail.com>

[Greg Young]

I looked at this a while ago.

I found that many of the tests in terms of my stories were not
actually in my ubiquitous language but were instead in what I deemed
the "shared language".

To be clear, my ubiquitous language is often quite complex and
requires a true SME in order to comprehend it's meaning. Often my
users in my stories are not SMEs and as such have a simplified version
of the system (as if viewed through a facade). This process happens at
all levels though the ones closest to the domain tend to be the ones
closest to the ubiquitous language.

I had written a post about this some time ago
http://codebetter.com/blogs/gregyoung/archive/2007/10/16/bdd-and-the-shared-language.aspx

Cheers,

Greg

On Tue, Dec 9, 2008 at 12:40 PM, Tore Vestues <tore.v...@gmail.com> wrote:
>

[Elizabeth Keogh]

On Tue, Dec 9, 2008 at 8:40 PM, Tore Vestues <tore.v...@gmail.com> wrote:
>
> How well does BDD work together with Domain Driven Design (DDD)?

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:
http://domaindrivendesign.org/events/oopsla2007/dan_north/

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
Scenario
Story
Narrative
Behaviour
Responsibility
etc.

...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
word "should".

Does this help?

Cheers,
Liz.

--
Elizabeth Keogh
l...@lunivore.com
l...@thoughtworks.com
http://jbehave.org
http://lizkeogh.com

[Tore Vestues]

Thank you for your answer.

In the video you're talking about several layers. Do I understand you
right if your tests are applied on every level, not just the outer
user interface/user stories level? And on the lower levels you will
write BDD-style-tests on the domain model itself (which was kind of
what I was looking for)?

What is confusing me a bit here is how BDD kind of looks like just
writing acceptance test/integration tests, and not really testing
every unit of code.

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.

- Tore Vestues

On Dec 10, 12:41 am, "Elizabeth Keogh" <l...@lunivore.com> wrote:

[Elizabeth Keogh]

On Wed, Dec 10, 2008 at 12:46 AM, Tore Vestues <tore.v...@gmail.com> wrote:
>
> In the video you're talking about several layers. Do I understand you
> right if your tests are applied on every level, not just the outer
> user interface/user stories level?

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!

http://lizkeogh.com/2008/12/10/given-when-then-and-examples-for-classes/

> 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).

[Tore Vestues]

Great!

Now I see how it all works together, and how BDD and DDD works very
well togheter indeed.

Thanks for your replies.

- Tore Vestues
http://tore.vestues.no

On Dec 10, 8:22 am, "Elizabeth Keogh" <l...@lunivore.com> wrote:

[Dan North]

Hi Tore.

I'm coming in a bit late to this but I couldn't resist trying to answer your question. I see you've already had some great replies.

2008/12/9 Tore Vestues <tore.v...@gmail.com>

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.

Excellent question! I put together a talk earlier in the year about the relationship between BDD and DDD. The core message is the idea that DDD is about creating a vocabulary and a model (usually various models) of your domain, and that BDD is then about the conversations you have with that vocabulary. In other words BDD is about how you combine your various domain constructs to create useful behaviour in your application.

In that regard, DDD is a design philosophy whereas BDD is a development methodology. This means DDD - in my opinion - is a much broader and more powerful idea. You can use DDD to model a whole series of complementary domains across an entire organisation. In fact even if you didn't write any software, the activities around domain modelling and identifying your core and supporting domains would be a valuable exercise in its own right. "Strategic" DDD - the second half of the blue book - is actually a powerful pattern language for modelling organisations.

(I showed the talk to Eric Evans and he liked the overall message, but we both agreed the it was a bit of a simplification and that actually the relationship is much more interesting and bidirectional.)

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
model?

Not really. Stories in BDD are from the point of view of a stakeholder, who isn't necessarily a user. There are lots of stakeholders in any software project. Initially you have the people whose problem you are trying to solve - namely the users and the project sponsor (the person with the chequebook!). I call these the "core stakeholders". Then as you start to solve the problem you introduce a number of other stakeholders. Your security people, the legal folks, networking and infrastructure, operations, support - these are also all stakeholders because your work affects them. I call these "incidental stakeholders". And don't forget the team members themselves are also stakeholders.

You can describe value-adding work from the point of view of any of these people, and that is how BDD arranges its work. You have stakeholders defining stories and acceptance criteria (scenarios) for those stories. Then the stakeholders all agree on a priority order (should the story about SQL injection attacks be played before or after the address capture? the system can't go live without it but do we want to play it yet?).

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.

I couldn't agree more! That's why I use the term "stakeholder". My working definition of stakeholder is "anyone who cares" about the application you deliver.

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?

Yes. It is vitally important that stories are expressed in the most appropriate language for that stakeholder. This is also a good way of avoiding implementation details in the story. So "Capture a name and address" is more useful than "Enter name and address in text fields and pressing a submit button". The domain of names and addresses is separate from the domain of web form widgets like text fields and submit buttons so it doesn't help to couple them together in the story text.

I'm really hoping you can provide me with some insight here.

Me too!

- Tore Vestues

Cheers,
Dan

[Colin Jack]

> What is the difference between an end user of the system and a domain
> expert?

This post from Eric Evans lists a few roles business people can take
in a project:

http://tech.groups.yahoo.com/group/domaindrivendesign/message/9070

Ultimately DDD doesn't work without domain experts, who quite often
have a radically different view on things than the users do.

[Colin Jack]

> Excellent question! I put together a talk earlier in the year about the relationship between BDD and DDD.

Are you aware of whether this talk available anywhere?

> Not really. Stories in BDD are from the point of view of a stakeholder, who isn't necessarily
> a user. There are lots of stakeholders in any software project

This all makes sense but this aspect confused me when I started
learning BDD though and although I haven't re-read the BDD articles
recently I'm pretty sure sure they don't discuss this in any detail so
I'm wondering if its something that is worth revisiting?

> You have stakeholders defining stories and acceptance criteria (scenarios) for those stories.

One thing I think you get when working at the domain level is a lot
more acceptance criteria that suit a tabular format.

For example if we're developing a system to calculate fees then once
we have the model we'll have a lot of requirements of the form "if the
customer is in network X and have atleast £Y in their account, and
if....then we will charge Z%". Not how I'd write them of course, but
the point is we'd have this sort of acceptance criteria over and over
for different situations.

Trying to write these up in the G/W/T format seems to me to be a
little un-natural, you have one or very story/features with a massive
number of scenarios attached and it just isn't a naturally way to
write them (in my experience anyway). This is why I'm very interested
in the Cucumber approach as it makes me think I'll be able to have my
cake and eat it too:

http://github.com/aslakhellesoy/cucumber/wikis/using-fit-tables-in-a-feature

[Colin Jack]

> 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.

The heavy focus on outside-in is fine but when I've worked on projects
that had any significant domain complexity there were at least two
steps to the process:

1) User Stories - Gathering user stories and acceptance criteria (or
use cases) with QA/users/BA/developers/others. This led to UX design
and whatever else.
2) Domain Model - After we had user stories/acceptance criteria the
developers/BAs/domain experts would work on the model.

These quite often continue in parallel, the first informs the GUI/
controller design and the second the domain/services (and related
rules/constraints).

So really I'm wondering, in this world would you consider outside-in,
from the domain experts viewpoint, to be from the domain in?

[Jonathan Parker]

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?"

I guess what I'm getting at is that the level of analysis that one should go to depends on the level of analysis that has previously been done by the core stakeholders before they call you to help them out. If the full extent of their analysis is that "We need to save money." then there is likely room for more analysis which is outside the behaviour of the system and more inclusive of the behaviour of the users. I know that users behaviour is supposed to drive system behaviour, but what drives user behaviour?

More!

Is it possible for a user interface to be a person? You mention in your video that not all stakeholders are users, however if you loosen the definition of user you could say that the CEO is a user via his workers. I.E. He will ask them about how the system is working, what the success of it is etc. This ultimately is dependent on the users themselves which is dependent on the software.

Therefore the use interface for the CEO is the spreadsheet report saying $x saved or $y lost due using the software.

[aslak hellesoy]

On Sun, Jan 11, 2009 at 10:15 AM, Jonathan Parker <jonathanp...@gmail.com> wrote:

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?

In this case you facilitate a conversation with the two of them and ask "why" until everybody understands the business value of having advertisements on LCD screens. Will it lead to increased income? Will it help manage costs? Prioritisation should happen after that, not before.
 

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."

I usually try to avoid user interface lingo in scenarios/examples.

I'm going to sidetrack a little from the UX focus here...

How can a stakeholder verify that a record is saved? Saving a record isn't valuable on its own. The value of a system is comprised of what comes *out* of the system, not what you put *into* it. Examples of output are seeing a report (gui, pdf), sending a message to an external system (email, REST web service invocation).

I would rather say something like "I can see the record in a list after it's saved".

Scrum has the 'V' in INVEST moniker to capture this - every story should be valuable. In BDD the value is described in the header section of a story.

Teams have a tendency to break up valuable user stories into smaller, non-valuable ones, so they can maximise their own story points. This is something I usually try to avoid.

If you follow the Given-When-Then style, the Then steps should describe something that comes out of the system. Something the user can observe, and that is related to business value.
 

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?"

The whole UX aspect is really interesting. I just facilitated a 3 day BDD case based workshop with 30 colleagues where there was one UX person and 3-4 programmers on each team. What I observed was that the process they followed was a little different from what I have seen on pure-developer teams. They produced paper prototypes for the high priority stories and involved the customer a lot more. A lot more detail about UX was captured and the end result was actually usable :-).

Another thing I saw was that the user stories had a much bigger focus on output and the process a user is trying to follow. A UX designer is interested in how the user gets the job done with the help of the system (and therefore, a "save" story is less likely to be written).

Aslak
 

[Jonathan Parker]

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?

[aslak hellesoy]

On Sun, Jan 11, 2009 at 11:18 PM, Jonathan Parker <jonathanp...@gmail.com> wrote:

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?

I never keep this kind of information in user stories. I do however say things like:
The average response time with 50 concurrent users should be less than 100 ms.
Users don't care how you solve it (CPU, RAM, IO etc).

Aslak
 

[Jonathan Parker]

But aren't operations guys also users? If they have to spend their whole day rebuilding indexes etc. then this will increase operational costs when reducing them could have been the reason for the software in the first place.