The last few months I have been sitting here fairly smugly saying there is nothing in BDD for me to understand (and have met others sitting with the same opinions). It's just TDD + DDD reframed into a way that is easier to teach to developers who are new to the concept (as part of a great explanation by Aaron Feng and further discussed with Raymond Lewallen).
There are however many differences and in my opinion DDD and BDD should never even be compared to each other as they have almost nothing in common. As we shall see with the differences they are about language whether for our development team or for the project as a whole...
This afternoon I emailed Scott Bellware about some concerns I had with BDD. After work (and each of us each going away for a moment for refreshments to partake in during the discussion he a pumpkin ale and I a Corona) we had one of the most intellectually interesting discussions that I have had in a long while...
I posed to Scott the following BDD concern ...
BDD is often described as being TDD + DDD. When I look at the artifacts generated from BDD though I tend not to see what I would consider to be part of the Ubiquitous Language but something which is at a higher more naive level (similar to what Evans describes in finding obvious nouns *see below*). How does BDD
1) Find the deeper model as we do in DDD
2) Move forward with the ubiquitous language as the artifacts will require vast refactoring in order to keep pace with the model and as it said in DDD "Documents should compliment code and speech" thus it is imperative that these artifacts stay updated with the current ubiquitous language.
The mention of Evans in regards to obvious nouns here specifically relates to DDD page 30:
"The detachment of speech from other forms of communication is a particularly great loss because we humans have a genius for spoken language. Unfortunately, when people speak they usually don't use the language of the domain model.
That statement may not ring true to you initially, and indeed there are exceptions. But the next time you attend a requirements or design discussion, really listen. You'll hear descriptions of features in business jargon or layman's versions of the jargon. You'll hear talk about technical artifacts and concrete functionality. Sure you'll hear terms from the domain model; obvious nouns in the common language from the business jargon will typically be coded as objects, and those terms will tend to be mentioned. But do you hear phrases that could even remotely be described in terms of relationships and interactions in your current domain model?"
To be clear :
When I look at the stories that come out of BDD I see the stakeholder describing their model, this is not the same as in DDD where the stakeholders and the developers work to define an ubiquitous language. I will use Dan North's canonical examples in his whats in a story post::
Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed
Scenario 1: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
And the card should be returned
Scenario 2: Account has insufficient funds
Given the account balance is $10
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should not dispense any money
And the ATM should say there are insufficient funds
And the account balance should be $20
And the card should be returned
Scenario 3: Card has been disabled
Given the card is disabled
When the Account Holder requests $20
Then the ATM should retain the card
And the ATM should say the card has been retained
We can see exactly what Evans discusses. This story talks of pre and post conditions and will certainly not be relevant in what will eventually be our ubiquitous language if we head down a DDD path, obvious nouns are described but there is little to model off of (this simply brings up questions). Many changes will need to occur as this becomes an ubiquitous language.
When we look at the above text we do not see a true domain model developing. We see a model through the looking glass of a facade (BDD seems excellent at describing facade boundaries!). We see being formed as artifacts things which are merely describing a facade to our model that we intend to keep and refactor into our ubiquitous language when it later develops!
Scott had a very simple reply...
I don't necessarily think a stakeholder cares (or should care) about the domain model. This is how they view the problem. (Scott blame the corona if I paraphrased you incorrectly)
At the moment I heard this I thought "sacrilege!" and was ready to throw out some more DDD "no no"s like from the view point of DDD "One Team, One Language" it would seem that BDD is falling into a trap already seen many times, quoting Evans:
Technical people often feel the need to "shield" the business experts from the domain model. They say:
"Too abstract for them."
"They don't understand objects."
"We have to collect requirements in their terminology"
These are just a few of the reasons I've heard for having two languages on the team. Forget them.
Of course their are technical components of the design that may not concern the domain experts, but the core of the model have better interest them. Too abstract? Then how do you know the abstractions are sound? Do you understand the domain as deeply as they do? Sometimes specific requirements are colelcted from lower-level users, and a subset of the more concrete terminology may be needed for them, but a domain expert is assumed to be capable of thinking somewhat deeply about his or her field. If sophisticated domain experts don't understand the model, there is something wrong with the model.
Alas, I too have had stakeholders such as what Scott describes. In fact thinking back many of them were in the sorts of domains that I would not recommend DDD and recently Eric Evans has also had had this discussion.
I became more and more aware that one of the basic mistakes that model enthusiasts made from the start was the idea that we should just model everything, that the whole system should modeled and object oriented and so on. what I have started to realize is that that dilutes the effort to the point where we don't really ever get the bang for the modeling buck and that in fact most systems are probably 90% CRUD (create, read, update, delete) and that there are simpler solutions to that problem.
BDD != DDD not even close. Can I say this loud enough? BDD is focused on the cases where DDD does not come into play. In other words for those who remember these types of problems from the SAT ...
BDD is to DDD as Active Record is to Domain Model.
Unless a grand effort is made BDD does not contain an Ubiquitous Language. It contains a [SHARED LANGUAGE] . Refactoring the BDD artifacts to keep up with the ubiquitous language is probably not a worthwhile task. Many stakeholders do not care to discuss a grand unified language they want their perception of the model to be implemented. Often times these are simple systems with fairly linear processes. The stakeholder doesn't give a crap if their is an Account,Transfer method or an AccountTransferService. To him these are details and it is this world that BDD tries to formalize.
BDD focuses on [SHARED LANGUAGE] between the development team and the stakeholder. This may be similar to DDD's Ubiquitous Language but is certainly not the same. The developers intentionally hide complexity behind a facade both architecturally and verbally from the stakeholder. In return the stakeholder provides [ACCEPTANCE SPECIFICATIONS] in the [SHAREDLANGUAGE] that the developers may then use as a basis to form an internal abstraction of the system.
Do I agree with BDD's [SHARED LANGUAGE]? In my discussion with Scott it was like any other problem I face "Well it depends". I know personally the benefits of a true Ubiquitous Language but at the same time I have dealt with stakeholders who were not that interested in such an effort. They did not care how I modeled the account class so long as from their external view point they saw it in the way they wanted to see it. They wanted the project done to a level of acceptance as fast as could be delivered in a maintainable way with lower TCO.
Note: there are also times when your experts aren't really experts either that this can be a good thing :)
As such we come to the root issue, is their lower TCO with an ubiquitous language or a shared language. I think the benefits of ubiquitous language over shared language are directly proportional to the amount of complex logic contained in a system compared to the amount of simple logic in a system (providing you want a unified model). In the long term I think BDD wins that 70+% of the time as it really is an amortization for the simple cases (it just has a much worse worst case).
I personally will stay with DDD but in general it is important to note that there is NO ubiquitous language with BDD, to maintain one is too difficult and costly, if you seek an ubiquitous language re-read DDD. Instead a [SHARED LANGUAGE] is used which can almost be viewed as a context mapping in DDD.
Side note: Scott had another very interesting quote worth mentioning when I tried looking at it as a matter of a DDD context mapping with the stakeholder being a boundary.
Its not a matter of looking at it differently, its a matter of looking at it at a different level of detail.
In terms of the elephant story when dealing with the elephant it is also important to not only see the bigger picture as the blind men had to but to recognize the viewpoint between a mouse looking at the elephant, a flea sitting on the elephants back, and a tapeworm living in the elephant!\
Music: The Ring of Fire, Johnny Cash "I fell into a burning ring of fire. Went down,down,down and the flames went higher. And it burns, burns, burns the ring of fire; the ring of fire"