Under what conditions could we justify an attempt to introduce a one size fits all term when it contradicts working experience?

I have just been re-reading "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans. I could not help but notice a hint towards creating a language where there is a one-to-one mapping between a noun and an entity. For example, we might call a phone, a phone and no other noun is accepted. However, can this always been achieved with every other entity. Let us take for example, language used to denote a bid on a phone. Here, there are several different names that refer to a bid on that phone where all these refering names mean the same thing, e.g., negotiate bid, negotiate offer, phone bid, etc. Also, there are additional terms used by other customers. Using these terms interchangably does not cause confusion. Nevertheless, attempts to introduce a single term to be used across all the source code as well as in conversations with all customers can cause confusion.

There is the obverse problem when we talk about similar phones where similar means something different to each customer. Here, we have the same term, which is sought after. However, it has many different meanings.

So, what justification in this instance could be used to attempt to introduce a one size fits all term when it contradicts working exper开发者_如何学运维ience?

Your argument "begs the question" (in the logic sense of the term).

You ask: "Under what conditions could we justify an attempt to introduce a one size fits all term when it contradicts working experience?" How about under those conditions where it actually doesn't contradict working experience?

You suggest: "attempts to introduce a single term to be used across all the source code as well as in conversations with all customers can cause confusion." Indeed, it can... and it can also avoid confusion.

Source code is a great example of a limited domain where we can expect a minimum level of familiarity and training for all of the users expected to work in that domain (at least, in most commercial settings).

It is quite reasonable for a style-guide to declare the preferred term, and expect everyone to follow it, as consistency in this situation has a big upside. Using your example, in my particular project, I use the term "offer" over "bid" every time, and the code is better for it. I can point to other terms which have not yet been standardised, and can see the extra effort it takes to code for them.

Similarly, it is a widely accepted design goal in User Interface design and in User Documentation to use consistent terms. Using multiple terms for the same item is more difficult for users to follow - particularly non-native speakers. (I disagree with your claim that it does not (ever) cause confusion.) When introducing a new term, it is a good idea to mention other terms that could be used.

(Funnily enough, I worked at an organisation where the User Documentation referred to phones as "Voice Terminals", as the term 'phone' was ambiguous; this was, I suspect, going too far?)

On the other hand, someone selling a product or training users would generally do well to mimic the language of the users to best engage them.

You said,

There is the obverse problem when we talk about similar phones where similar means something different to each customer. Here, we have the same term, which is sought after. However, it has many different meanings.

What about bounded contexts? Probably, when same term means two different things, they should reside in two different contexts?

I quote from Martin Fowler's page on Bounded Context:

As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. The precision of modeling rapidly runs into this, often leading to a lot of confusion. Typically this confusion focuses on the central concepts of the domain. Early in my career I worked with a electricity utility - here the word "meter" meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty).

His and yours problem descriptions sound similar.