In a post in his weblog, Greg Young posits that there is, and should be, a separate “[Shared Language]” that is distinct from (or orthogonal to) the Ubiquitous Language (UL) we discuss is the context of Domain-Driven Design (http://codebetter.com/blogs/gregyoung/archive/2007/10/23/bdd-and-the-shared-language-the-stakeholder.aspx)
The premise is a statement in the entry, as follows:
A stakeholder may or may not be a domain expert. If a stakeholder is not a domain expert do they belong in the inner-circle of your team? In other words to they deserve to be privy to your ubiquitous language?
My answer is: Of course they should be privy. The Ubiquitous Language is not a secret that the development team keeps to itself. It is meant to be a shared vocabulary for discussing elements of the application regardless of the level of the contribution; from Sponsor, to Stakeholder, to Analyst, to Developer, to Tester.
Speaking of stakeholders, Greg goes on to say:
With this customer you should absolutely NOT discuss the model in the ubiquitous language as it only exists within your development team (whatever your code is at any given point is your defacto ubiquitous language as you all understand the code) and it likely does not represent reality in the slightest.
I can’t disagree more.
(Well that’s not entirely true. Dismissing my desire to speak directly to the target users, I had a business analyst tell me that “There is no way you can trust the users to know what they want. I’ve seen too many cases of ‘Lost in Translation'”. “Exactly!”, I said. But I digress).
If there’s one way to get stakeholders on board, and keep ’em there, it’s to adopt a language that’s close to the one they know about their domain (it’s their domain too) and to be able to discuss their issues, concerns and desires for the application in that language. I’d go so far as to say that if the ‘Stakeholder’ doesn’t understand your UL, they are a stakeholder in name only.
I believe very strongly that that language needs to span all aspects of the development effort. In fact, if the code isn’t expressed in the Ubiquitous Language, I’m going back to my developers with a refactoring tool and a set of instructions to rename appropriately. By-the-way, code = application code + test code.
To me, using the UL everywhere is every bit as important as test coverage (with depth, before I get the ‘coverage isn’t everything’ comments).
Behavior-Driven Development (BDD) is nearly orthogonal to Test-Driven Development too. If you are doing TDD properly, it largely renders BDD unnecessary — at least if you do TDD the way I do. And the tests are expressed in the UL as well.
BDD is an executable specification technique. If one is disciplined with TDD you are writing executable acceptance criteria and requirements. They are similar, but different.
In either case, they should use the Ubiquitous Language.