Dear Junior
When walking the round trying to establish a new term in the ubiquitous language of a system, it is very tempting to start accepting synonyms.
Perhaps we tried to make 'username' explicit in the model. We then need to settle what a username is, and how it is checked against its validation rules. Among the programmers, we have used “username”. When we get over to the GUI designers they tend to talk about it as the “handle”. Later on we find out that the tech writers dig the term “alias”, and that is what they have used in the manual. It might seem tempting to say “we all mean the same thing, so lets accept these as synonyms” where after we write three entries in our glossary
“username, …”,
”handle, see username”, and
alias, see username”.
So, is that so bad? I guess we can handle three words meaning the same thing. Well, the problem is not the single words, it is the language and in the combinatorial explosion.
We also need to define what we call when we control that a username fulfils the formatting rules. It turns out that we preferred “validate”, however those that were on the Gazunga project (disregarding department) seem to prefer “checkup”. Let us accept these as well and add to our glossary
“validate …”, and
“checkup, see validate”.
Even if each word have a very limited number of synonyms, we now have lots of synonyms for phrases (remember that when a glossary is about words, the ubiquitous language is about phrases). There are six synonym prhases for “validate username”.
- “validate username”
- “validate alias”
- “checkup handle”
- “validate handle”
- “checkup alias”
- “checkup username”
Further on, the user account are by some referred to as “pref-set” (preference setting space), and by some as “area” (as in private work area). So, now there are no less that eighteen ways to phrase “validate the username of the account”.
Et cetera, you get it.
So, letting synonyms into the ubiquitous language quickly leads to having not one language, but a lot of dialects that quickly drift apart to form separate languages – and the ubiquity is gone.
Of course there are occations when you have to accept synonyms. If there is an established terminology outside the project there is a point in adhereing to it – but what to do if there are several competing standards. For example, the finance department might want to use the accepted term “imbursement”, but the marketers insist that the established term in our customer base is “money-forward” – both fully acceptable external bodies. In these rare cases we have to accept synonyms, but I still advice to denote either of them as the primary term, and only use the other when necessary. In the glossary it might say “money-forward (aka imbursement), a payment made by … in exchange for… (imbursement preferred by finance department)”.
By all means, do use synonyms when they are absolutely necessary, but be very restricted. I promise, if you allow synonyms at an early stage, then confusion will arise somewhere down the road.
Yours
Dan
ps When trying to avoid synonyms you in many ways have the same mind-set as when establishing a canonical data format in the model - but you work in slightly different areas.