Ubiquitous Language in Product Development

Hi there.

I got this question from a fellow named Martin today:

Real simple … most of the discussion on DDD surrounds the design in terms of the ubiquitous language.

What if you are developing a product that is designed to be a tool for
a certain industry, say marketing, but the processes and terminology
all differ according to the marketing company that is in discussion.

To be specific, one company may use the term Client and the other Customer?

How do you accommodate the difference in terms?  Do you code to a common denominator or do you just pick one and go?

Great question; in product development we’re often trying to make a general solution that solves the common problems of customers that have different languages. There’s no way around that.

First, find those elements that are universal. Question if there’s really a need for all of this customization or if your clients are OK with calling a client a customer. Having a ubiquitous language that can be used end-to-end, from developer to end user, is extremely valuable and kind of the original point.

For variable terms you should, in my estimation and experience, form an internal ubiquitous language that’s adhered to across product management and software development. In cases like this, you’ll can potentially also apply DDD guidance to a generic subdomain that handles terminology. This domain usually goes by the name “localization,” only slightly extended to allow clients to change terminology. This is exactly how we handle the differences in terminology (silly) between agile methods like Scrum and XP in our product at VersionOne. We simply have a set of components that handle the change between backlog item and story, iteration and sprint, etc.

This entry was posted in DDD, product development. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

6 Responses to Ubiquitous Language in Product Development

  1. Cy says:

    I think that when you are developing *generic* software for an industry, rather than a specific client, the Ubiquitous language can’t cover all parties and you end up with a training issue. You have to make the call on what you will call items (input from a few clients will help keep it relevant to people outside your company) and then make sure that you reinforce the naming with training, etc. You may find that your terminology helps some companies clarify their language as well.

  2. Ian Cooper says:

    One thing to watch for here is that the differing terms do not elide some complexity. Client vs. Customer may represent a different perspective that might imply a different workflow or set of features. There can often be insights in uncovering why someone is using one word or another. The difficult part is that you can’t always fix this by saying “you mean a ‘Customer’ right’ ” to the person that says Client because you get confirmation bias; people just nod and agree because they think that is what you want to here.

  3. John Cerrano says:

    CSDD …nice! you should coin that

  4. Dave Laribee says:

    Yes. CSDD (Common Sense Driven Development) is my new thing.

  5. roger says:

    makes sense

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>