我們的項目團隊成員是從領域驅動設計社區通用語言概念的忠實粉絲。通用語言 - 術語，開發者和用戶
這裏是我們已經發現了問題：
非易怒的用戶喜歡使用的所有概念的簡化的名字，他們不想知道所有的細節，這是很正常的。但是我們不能在代碼中做同樣的事情，因爲這些概念並不像我們向用戶表示那樣簡單。
示例：用戶可以設置項目併爲其選擇任何模板。 但內在 - 它是Vendor1框架的概念，它是我們軟件的第三方組件。
因此，我們作爲開發人員可能會被用戶對「模板」術語的使用所困惑。因爲我們已經習慣在我們的MVC框架中使用「模板」術語。
我們現在有暫時的解決方法是：
我們應該如何解決這個問題？
有點晚接聽這裏...
你已經清楚地得到了「過載條件」這裏，這裏每一個「模板」是不同的，但在適當的情況下有效的問題。
我的做法是：
讓大家知道，「模板」在不同的上下文不同的含義。如果一個人必須處理不同的情況，這是至關重要的。
無論何時使用它，都要在單詞「模板」前面加上前綴。例如。使用「MVC模板」或「[供應商]模板」或「[域]模板」。所有文物（代碼/文檔）都清晰簡明，無需參考翻譯文檔。
重點清晰度在簡單（特別是如果attemping讓事情「簡單」會導致問題）
它不晚。我正在等待你的回覆:)謝謝，有趣的做法。 – ep3static 2009-10-26 10:10:59
與領域專家交談時使用簡單名稱。實施域模型時使用相同的簡單名稱和概念。在要求的域模型中實現相同的簡單需求。在域模型中不應該有這樣的東西，但領域專家從來沒有聽說過這個。
在其他層使用花式和科技的東西。如果您使用第三方工具 - 在那裏使用它們不直接進入領域模型。
你可以使用，以及上下文映射定義不同的環境和自己的邊界。 此外，您可以使用建模（DSL，UML配置文件...）將域和代碼分開，並通過模型驅動的方法（例如代碼生成）將它們帶回。 其實無處不在的語言的目的是解決這些衝突，所以你應該找到某種共識。
幾年前，我在一個嘗試使用無處不在的語言的項目。它沒有解決。沒有領域專家買入。他們對同一個概念有19個術語，並希望保持這一點。他們想要與發展交戰。在那個項目上，我們最終創造了「UDickedWithUs語言」一詞。當領域專家由於工作安全問題而不敢分享時，這種反模式偶爾會出現。我在其他項目上用無處不在的語言運氣很好。第一個註定要失敗的企業文化問題。 – 2009-10-26 09:22:28