Domain driven design 在什么情况下，我们可以证明在与工作经验相矛盾的情况下尝试引入“一刀切”的术语是合理的？

我刚刚重读了Eric Evans的“领域驱动设计：解决软件核心的复杂性”。我忍不住注意到了一个关于创建一种在名词和实体之间有一对一映射的语言的提示。例如，我们可以打一个电话，一个电话，不接受其他名词。然而，这一点在所有其他实体中都可以实现。让我们举个例子，在电话上用来表示出价的语言。在这里，有几个不同的名称表示该电话上的出价，所有这些名称表示相同的事情，例如，议价、议价、电话出价等。此外，还有其他客户使用的其他术语。交替使用这些术语不会引起混淆。然而，试图在所有源代码中以及在与所有客户的对话中引入一个术语可能会引起混淆

当我们谈论类似的手机时，存在一个正面的问题相似对每个客户来说意味着不同。在这里，我们有同样的术语，这是人们追求的。然而，它有许多不同的含义

那么，在这种情况下，当一个一刀切的术语与工作经验相矛盾时，有什么理由可以用来尝试引入一个一刀切的术语呢？

你的论点“回避了这个问题”（在术语的逻辑意义上）

你会问：“在什么条件下，当一个“一刀切”的术语与工作经验相矛盾时，我们可以证明引入这个术语是合理的？”那么，在这些条件下，它实际上与工作经验不矛盾呢

您建议：“试图在所有源代码中以及在与所有客户的对话中引入一个术语可能会导致混淆。”事实上，它可能。。。它还可以避免混淆

源代码是有限领域的一个很好的例子，我们可以期望在该领域工作的所有用户（至少在大多数商业环境中）都能获得最低程度的熟悉度和培训

样式指南声明首选术语并期望每个人都遵循它是非常合理的，因为这种情况下的一致性有很大的好处。以您的示例为例，在我的特定项目中，我每次都使用术语“offer”而不是“bid”，代码更适合于此。我可以指出其他尚未标准化的术语，并且可以看到为它们编写代码所需的额外努力

同样，在用户界面设计和用户文档中，使用一致的术语也是一个被广泛接受的设计目标。对同一项目使用多个术语对用户来说更难理解，尤其是非母语人士。（我不同意你的说法，即它不会（永远）引起混淆。）在介绍一个新术语时，最好提及可以使用的其他术语

（有趣的是，我在一家组织工作，那里的用户文档将电话称为“语音终端”，因为“电话”一词含糊不清；我怀疑这太过分了？）

另一方面，销售产品或培训用户的人通常会很好地模仿用户的语言来吸引他们。

你说过

当我们谈论相似的手机时，正面的问题是相似对每个客户来说意味着不同。在这里，我们有同样的术语，这是人们追求的。然而，它有许多不同的含义

有界上下文呢？也许，当同一术语意味着两个不同的事物时，它们应该存在于两个不同的上下文中

我引用Martin Fowler的页面：

当您试图对一个更大的领域建模时，构建一个统一的模型变得越来越困难。在一个大组织的不同部分，不同的人群会使用细微不同的词汇。建模的精度很快就达到了这一点，常常导致很多混乱。这种混淆通常集中在域的中心概念上。在我职业生涯的早期，我曾在一家电力公司工作过——在这里，“电表”一词对公司的不同部门意味着微妙的不同：它是电网和一个地点、电网和客户之间的连接，还是物理电表本身（如果有故障，可以更换）

---

他和你的问题描述听起来很相似。

我也能想出与工作经验不矛盾的例子。然而，它在某些情况下确实存在矛盾，这表明“一刀切”的方法是有缺陷的。此外，我同意，在大多数情况下，对特定术语进行标准化可以避免混淆。正如我的问题所表明的，我对例外情况很感兴趣。我仍然会对你的答案投赞成票，因为我不加批判地认识到了他的处方中的一些缺陷