Behavior-Driven Development is a Specification Technique.. It Should Use the Ubiquitous Language

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 (

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.


2 thoughts on “Behavior-Driven Development is a Specification Technique.. It Should Use the Ubiquitous Language

  1. To be fair I feel horribly misquoted here: you left out both the customer I said you should not discuss the ubiquitous language with and the last statement which justifies the quote in explaining the true reason *why* you shouldn’t .. I will include them.

    The customer: “What this stakeholder (read: not domain expert) cares about is that the software that they want built gets built. They are interested in [ACCEPTANCE SPECIFICATIONS] and insuring that they are communicated well to the team who they expect to magically make happen.”

    and of course the most important part that was left out of the quote (the last sentence)

    “You will also most likely not be using DDD unless your team also just so happen to be domain experts …”

    You have no domain expert! So your UL is ridiculous and only makes sense to your technical team. You are not using DDD so yes absolutely the ubiquitous language flies out the window.

    I agree that you need a language but you use the only thing left that makes sense to discuss with your stakeholder… the same naive terms that they defined their acceptance criteria in … stakeholder is not a domain expert …. you are not a domain expert … how do you refine the language without bringing on a domain expert? DDD ceases to apply and so does the UL but the [shared language] can be extremely beneficial.

  2. I am usually accused of over-quoting..

    Actually, I think I did include all those people you say I left out, I just included them implicitly,

    My main objection was to the specific exclusion of a particular type of contributor to the process, as ‘not deserving to be privy to your ubiquitous language’.

    My point was, and is, that you need input and feedback from everybody and to get that the best way is to use the UL.

    BTW, I don’t distinguish between domain experts and users/stakeholders/etc. That’s who they are.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s