Let’s clear things up about BDD’s [SHARED LANGUAGE], its usage, and that it may or may not be a subset of the ubiquitous language in order to express its value. In case things were not clear the main difference between the [SHARED LANGUAGE] and the ubiquitous language is that with our [SHARED LANGUAGE] we deliberately hide complexity within our stories.
To be clear in response to a comment: yes I know that BDD is attempting to define an ubiquitous language for stories and that is in no way what I am talking about in this nor the former post.
One Team One Language
I went a bit overboard with one of my analogies in that BDD is to DDD as AR is to DM the two can in fact be orthogonal when used properly. I also muddied the waters a bit by using the term ‘stakeholder’ throughout the previous post. So let me explain a bit more about BDD’s [SHARED LANGUAGE] and how it can function in a project.
As I have said, one mistake I made in explaining the [SHARED LANGUAGE] appropriately was my misusing of the term ‘stakeholder’. This is the key distinction between the application of the [SHARED LANGUAGE] vs an ubiquitous language or a combination of the two.
One of the key concepts of the ubiquitous language is that the entire team should be using it… But … what defines the team?!
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?
I lean towards no in this case. Why? because they probably won’t understand the ubiquitous language in the first place because they have not been involved enough in the domain or simply do not care to be involved at such a depth. The latter of these positions was so eloquently put by Scott in the previous post as:
I don’t necessarily think a stakeholder cares (or should care) about the domain model. This is how they view the problem.
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.
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. You will also most likely not be using DDD unless your team also just so happen to be domain experts …
Your [SHARED LANGUAGE] may or may not represent a subset of the ubiquitous language of the project and it does not matter. Define your facade boundary of the domain using BDD and the [SHARED LANGUAGE] but model your system differently internally. Hide this complexity from the non-domain expert stakeholder(s) whether they don’t know or don’t care doesn’t change the fact that it should be hidden from them.
What if however your stakeholder(s) IS also a domain expert. When dealing with smaller systems this is often the case. In this case the [SHARED LANGUAGE] in many ways loses its value and it becomes simply an iteration towards the ubiquitous language. This situation can be tricky.
When you are dealing with this situation and using both DDD and BDD you will end up in a situation where BDD creates a lot of artifacts that according to DDD must be kept up to date with the ubiquitous language as the people who are dealing with are part of your inner-circle and to not do so would lead to a segmentation of your teams language.
I am not quite sure whether the keeping up to date of these artifacts is worthwhile (and doesn’t seem very agile)… but I think this is the most interesting are of discussion when it comes to BDD and DDD.
A great option (imho) would be to use DDD and then recognize the segmentation of language between the ubiquitous language of your domain and the [SHARED LANGUAGE] just so happens to match your (remote) facade boundary and therefore keep them separated with your [ACCEPTANCE SPECIFICATIONS] being applied to the (remote) facade and its externally visible behaviors as opposed to within the domain itself.
What if I have stakeholders who are domain experts and stakeholders who are not? I think this is the normal case and is by far the most complex to maintain. Here we have a simple approach to keep BDD and DDD as orthogonal. We keep BDD based within the [SHARED LANGUAGE] while having our team maintain our ubiquitous language.
Is the [SHARED LANGUAGE] a subset of the ubiquitous language? Maybe but I lean towards a resounding no. By keeping the [SHARED LANGUAGE] as a subset of the ubiquitous language we take upon the team the responsibility to maintain the changes in the ubiquitous language and map them into the [SHARED LANGUAGE].
In fact as we have discussed the [SHARED LANGUAGE] does not look much like the ubiquitous language it looks like the ubiquitous language as viewed through a facade.
This does however leave our domain-expert-stake-holders in an awkward position as they need to be fluent both in the ubiquitous language to deal with conversing with the team and in the [SHARED LANGUAGE] for when dealing with the other stakeholders. If they are actually domain experts is this need to discuss their domain in varying terms an issue?
Have you noticed a theme? In every case I have shown how BDD and DDD can coexist by using BDD and the [SHARED LANGUAGE] to define [ACCEPTANCE SPEFICATIONS] at the point of the (remote) facade over your domain… So let’s boil this down to a more simple form.
- The ubiquitous language is a language that is internal to your team.
- The [SHARED LANGUAGE] talks about how the system is seen from the outside perspective of a non-domain-expert-stake-holder
- Your team may or may not include your stakeholders depending on whether they are domain experts.
- Stakeholders write BDD based [ACCEPTANCE SPECIFCATIONS] in the [SHARED LANGUAGE] which are then applied not to the domain itself but at the (remote) facade over the domain.
- A mutual team member (stakeholder and domain expert) should be fluent in both languages.
There are some places where things can get more interesting
(stake-holders-are-domain-experts) but for the most part this should keep you