3

This question might be a bit vague and answers might come up quite opinionated but I don't know how to rephrase it so here it goes.

How can a developer build a solid vocabulary when working in a specific domain?

As we all know, naming things is one of the hardest feats in this craft. Furthermore, it is highly likely for a developer to change numerous contexts throughout their career, from hotel bookings to finance to e-commerce etc. So they should have a pretty rich set of terms and words to choose from when building their systems.

What are the best steps one can make to improve in this direction? Thanks!

  • 2
    Given that the terms can differ within the same industry and even the same company, it would seem you're on a hiding to nothing with this one... – Robbie Dee Dec 19 '17 at 10:26
  • 1
    It's probably not worth beating yourself up over this. As @RobbieDee has mentioned, the terminology will even vary between companies in the same domain. What's important is to learn your current company's domain language. Have you ever looked into something called "Ubiquitous Language? – MetaFight Dec 19 '17 at 10:28
  • @MetaFight Yes, I've heard of Ubiquitous Language, I'll take a more detailed look at it though. Thanks! – Martin Shishkov Dec 19 '17 at 10:35
  • Funny story, I was discussing development of a program with a fellow programmer and we described it as a sort of bridge for building birt reports. We kept calling it birt bridge, and 12 months later, our company is demoing the software and it's official name is "birt bridge". I don't think there was ever a conscious decision to name it as such, but it became the terminology simply through repetition. I think most terms derive from convenience and usage. The rest are what we learned at school. – Neil Dec 19 '17 at 11:02
4

You are correct that building a rich and descriptive vocabulary for your domain is crucial for efficient communication. However, as mentioned in the comments, the reality is that, even in the same industry/domain, the actual terminology used will vary from company to company.

Domain Driven Design has a concept called Ubiquitous Language that kind of deals with this.

In an effort to simplify communication between the technical team and the domain experts, DDD recommends everyone involved on the project use the same language to when talking about the domain. For example, if the end-user calls it a doodad then it's a doodad when we speak about it, and it's a doodad when we code about it. Keeping the terminology the same everywhere (even in code) eliminates the need for translating terms between contexts and helps keep communication easy.

And, since we're typically building software for people who already have a natural way of speaking about their domain, it usually makes sense to use that as a starting point for your ubiquitous language (UL).

It is possible for the technical team to ask for refinements of the UL, but for the most part it is a domain-expert/end-user driven glossary of terms.

So, you can kind of dodge the problem of learning "industry-standard" terminology as long as you focus on using Ubiquitous Language.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.