Greg Young [MVP]

Sponsors

The Lounge

Syndication

Recent Posts

Tags

View more

News

Archives

Advertisement

Greg Young [MVP] » BDD and the Shared Language: The Stakeholder
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
BDD and the Shared Language: The Stakeholder

 

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.

  1. The ubiquitous language is a language that is internal to your team.
  2. The [SHARED LANGUAGE] talks about how the system is seen from the outside perspective of a non-domain-expert-stake-holder
  3. Your team may or may not include your stakeholders depending on whether they are domain experts.
  4. 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.
  5. 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 pretty safe.

Posted Tue, Oct 23 2007 3:00 AM by Greg
Filed under: , ,

[Advertisement]

Comments

Jason Haley wrote Interesting Finds: October 23, 2007
on Tue, Oct 23 2007 9:46 AM
jdn wrote re: BDD and the Shared Language: The Stakeholder
on Tue, Oct 23 2007 11:46 AM
It seems to me that you are trying to redefine what 'ubiquitous language' means. http://behaviour-driven.org/UbiquitousLanguage "A concept from DomainDrivenDesign. The aim of which is to establish a common consistent language structured around the problem domain that can be shared by the business users of the system and the developers. " It is *not* a language internal to your team to be hidden from view, yet you have redefined it as essentially the 'language' of the code. But that isn't what the term is usually taken to mean, in fact, it seems to me as far away from it as one could get. So I don't know what you mean. Which is really unfortunate since I'm trying to explain the concept to business users.
Greg wrote re: BDD and the Shared Language: The Stakeholder
on Tue, Oct 23 2007 12:08 PM

I do not believe that I am redefining the definition of ubiquitous language I believe I am using the definition actually explained in DDD and the one you have quoted is subtly incorrect.

In DDD itself  you will note that the discussions of ubiquitous language focuses on the communication between the DOMAIN EXPERTS and the development team not the business users. The definition on DomainDriven does not user the same terminology http://domaindrivendesign.org/discussion/messageboardarchive/UbiquitousLanguage.html

 

"Use the model as a backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing and especially speech."

Note use of the word "Team" 

 

to be clear ...

I am working on a point of sale system. A business user might the VP of franchising or a cashier/assistant manager in a location. These are not domain experts ... do you speak the ubiquitous language to them?

You may have a cashier who joins your team as a domain expert (to explain to you how the business works). In this case they should be spoken to in the ubiquitous language.

The ubiquitous language is not a language that is made to talk to anyone who cares to talk about the system. End users and many stakeholders still talk about the system in terms of screens, features, and functionality. 

"The aim of which is to establish a common consistent language structured around the problem domain that can be shared by the business users of the system and the developers."

 


I have however started a thread over on the DDD list to help come up with a consensus opinion.

jdn wrote re: BDD and the Shared Language: The Stakeholder
on Tue, Oct 23 2007 2:16 PM
It's the people who are actually using the system that generally drive requirements, so if they aren't part of the team, then it seems there is a huge gap there (what makes someone a business user as opposed to 'the cashiers' of the world who are actually using the system? Job title? I take it that the [Shared Language] is supposed to fill this role? (In which case, that's more important it seems than this ubiquitous language, but maybe that's just my experience).
Greg wrote re: BDD and the Shared Language: The Stakeholder
on Tue, Oct 23 2007 6:04 PM

It depends what you are talking about ....

In the [shared language] someone may say as in Dan North's ATM example:

Scenario 1: Account is in credit

Given the account is in credit

And the card is valid

And the dispenser contains cash

When the customer requests cash

Then ensure the account is debited

And ensure cash is dispensed

And ensure the card is returned

This is far from the way that a banking expert would describe the scenario (but this is how a non-domain-expert-stake-holder would view their [acceptance specifications]. We would probably talk about many other things like _how accounts are debited_ _how do we insure that the cash is dispensed_ etc etc...  The customer is hidden from these gory details that our team needs to deal with but those details are all very important when we talk amongst the team in the ubiquitous language. i.e. an AccountFundsMovingService or a CashMachineCommunicationsService without getting too into modelling etc etc. The ubiquitous language is just a much more detailed view of the system than the [shared language] (as said above the [shared language] is liek the ubiquitous language viewed through a facade)

Which of these is more important? in my mind BOTH are extremely important they are just important to different people.

ScottBellware wrote re: BDD and the Shared Language: The Stakeholder
on Tue, Oct 23 2007 7:04 PM
> A business user might the VP of franchising or a cashier/assistant manager in a location. > These are not domain experts ... do you speak the ubiquitous language to them? I would. At least, I'd speak the parts of the language that they know and use the experience to feel out the extent of their involvement with the whole domain by observing the language that they do know.
Behavior-Driven Development is a Specification Technique.. It Should Use the Ubiquitous Language « The Pragmatic Agilista wrote Behavior-Driven Development is a Specification Technique.. It Should Use the Ubiquitous Language « The Pragmatic Agilista
on Wed, Oct 24 2007 1:22 AM

Pingback from  Behavior-Driven Development is a Specification Technique.. It Should Use the Ubiquitous Language « The Pragmatic Agilista

jdn wrote re: BDD and the Shared Language: The Stakeholder
on Wed, Oct 24 2007 10:53 AM
"AccountFundsMovingService....CashMachineCommunicationsService" These are exactly somethings that I would say should *never* appear in the ubiquitous language. That is technical code speak about implementation details and seems to go against the entire idea of a ubiquitous language.
Greg wrote re: BDD and the Shared Language: The Stakeholder
on Wed, Oct 24 2007 1:47 PM

jdn: Those are facades that represent communications between context boundaries within my domain (see some of the services as discussed within the ubiquitous language in DDD).

If these things are not currently in your ubiquitous language then you don't have an ubiquitous language. Your domain experts are obviously being hidden from the details of the model.

jdn wrote re: BDD and the Shared Language: The Stakeholder
on Wed, Oct 24 2007 2:17 PM

Greg:  Well, I think we're going to have to agree to disagree, at least for now.  As I understand it, "AccountFundsMovingService" wouldn't appear in the model either.  That's an implementation detail.

The domain is the business domain.  I currently work in a credit card division of a financial institution.  The domain is about types of cards, how they are generated, controlled, monitored, used, etc.  

The domain expert qua domain expert knows nothing about services or anything like that.  He is an expert on the industry of credit cards (in actual practice, he might also know about technology, but that's a different role).  And the 'ubiquitous language' should be about credit cards.

From the short discussion on the Yahoo group (do you have to sign up for those to reply?), I think it is clear that the meaning of the term 'ubiquitious language' isn't clear (to echo a point you made there, I'm not saying I'm correct, and I would add that I wouldn't be surprised if I wasn't), and I'm not the only one who views the issue the way I've described it.

Greg wrote re: BDD and the Shared Language: The Stakeholder
on Wed, Oct 24 2007 3:27 PM

I agree but .... when we look at DDD as described by evans ... a service is absolutely part of the model... and becomes part of the ubiquitous language. It is absolutely not a technical detail to be hidden. This to me has become a completely separate and very good discussion :)

I personally am following the ubiquitous language as described in DDD by Evans. I find it interesting that so many people have seemingly redefined this term in so many differing ways as it really is the core of DDD. If you read through DDD take note to the discussions with domain experts, you will see words being used in the ubiquitous language like "services", "repositories", "contexts", etc

I included a quote in my email from chapter 2:

"The vocabulary of that ubiquitous language includes the names of classes and prominent operations. The language includes terms to discuss rules that have been made explicit within the model. It is supplemented with terms from high-level organizing principles imposed on the model (such as context maps and large-scale structures, which will be discussed in chapters 14 and 16). Finally this language in enriched with the names of patterns that the team commonly applies to the domain model"

while this is fairly vague the real deciding point for me in reading all of the example conversations with the domain experts who use terms from the model such as repository and services.

per :

"The domain expert qua domain expert knows nothing about services or anything like that.  He is an expert on the industry of credit cards (in actual practice, he might also know about technology, but that's a different role).  And the 'ubiquitous language' should be about credit cards."

They don't need to be a technology expert to understand the concept of a service or of a repository abstraction you in fact use these within the ubiquitous language to *hide* deep technology from the domain expert (I don't talk about a peristence model I talk about a xxxrepository which magically handles things). As such my model is not polluted with these technical details while there is still an understanding that the process happens...

By not discussing such things we are put into a point where we have 2 languages anyways and have fallen back to using a shared language (the technical team has a different view of the model than the domain experts)

per list: yes I think you have to sign up to reply.

jdn wrote re: BDD and the Shared Language: The Stakeholder
on Thu, Oct 25 2007 10:36 PM
Well, there are many different things going on here, from my perspective. I am very new to DDD/TDD/SDD(Sinatra DoBeDoBeDee) so after looking up some of the things that Evans talks about, I can see a bit more clearly why you take the position that you do. Having said that, when you have a reaction to a methodology/concept/whatever that seems to go against what Evans has to say, you have to stop and think. I'm more than willing to learn the proper use of terminology as determined by the knowledgeable community, but when it comes to brass tacks, it seems to me that the shared knowledge concept becomes more valuable than the concept of a ubiquitous language, if the former concept allows the inclusion of business experts while the latter excludes them. As the community evolves due to practical experience, it makes sense to incorporate that experience.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?