非英语域中的编程和通用语言（DDD）
我知道这里已经有一些与该主题紧密相关的问题，但是没有一个以泛在语言为起点，因此我认为这是合理的。 对于那些不知道的人：泛在语言是定义（口头和书面）语言的概念，该语言在开发人员和领域专家中均会使用，以避免因翻译问题和误解而引起的不一致和误传。您将看到相同的术语出现在代码中，任何团队成员之间的对话，功能规范以及诸如此类的内容中。 因此，我想知道的是如何处理非英语领域中的泛在语言。 就个人而言，我极力主张完全用英语编写编程代码，包括注释，但当然不包括常量和资源。 但是，在非英语域中，我不得不做出以下决定： 用域的自然语言编写反映通用语言的代码。 将无处不在的语言翻译成英语，并停止以该领域的自然语言进行交流。 定义一个表，该表定义无所不在的语言如何翻译成英语。 这是基于这些选项的一些想法： 1）我强烈反对混合语言代码，即使用非英语的类型/成员/变量名称等进行编码。大多数编程语言都在很大程度上“促进”英语，并且大多数技术文献，设计模式名称等也是英语。因此，在大多数情况下，根本无法完全使用非英语语言编写代码，因此您最终还是会使用多种语言。 2）这将迫使领域专家开始以与UL等效的英语进行思考和交谈，这对他们而言可能并非自然而然，因此会严重阻碍沟通。 3）在这种情况下，开发人员以其母语与领域专家进行交流，而开发人员则以英语进行相互交流，最重要的是，他们使用UL的英语翻译编写代码。 我确定我不想选择第一个选项，并且我认为选项3比选项2更好。我是否缺少其他选择？ 更新 今天，大约一年之后，我每天都在处理这个问题，我不得不说，选择3对我来说非常有效。 这并没有我最初担心的那么乏味，在与客户交谈时进行实时翻译也不是问题。 根据我的经验，我还发现以下优点是对的。 翻译UL使您更加关注定义UL甚至域本身，尤其是当您不知道如何翻译术语并且必须开始浏览词典等时。这甚至使我重新考虑了域建模决策几次。 它可以帮助您使您对英语的了解更加深刻。 显然，您的代码看起来更令人愉悦，而不是让人讨厌。