将外部数据转换为您正在编程的语言

我不确定该怎么做：

我们从自己工具中的外部工具获取数据。该数据用荷兰语编写。我们正在用英语编写Java代码。然后我们应该将此荷兰语翻译为英语还是保留为荷兰语？例如，我们有两个部门：Bouw（英语建筑）和Onderhoud（英语维护）。

创建逻辑是否合理：

public enum Department { BOUW, ONDERHOUD }

要么：

public enum Department { CONSTRUCTION, MAINTENANCE }

甚至：

public enum Afdeling { BOUW, ONDERHOUD }

（在荷兰语中系部门）

在这种情况下，我将枚举值保留为荷兰语：

public enum Department { BOUW, ONDERHOUD }

因为使用这些常量的逻辑将与荷兰语中的数据匹配。例如，如果输入为“ bouw”，则比较代码如下所示：

if (Department.BOUW == input.toUpper())

当值匹配时，我发现更容易调试（即使我不知道值是什么意思）。翻译只是增加了一个心理障碍，作为开发人员，我不必跳过以证明其正确性。

但是，如果代码可以帮助其他人理解数据的上下文，则可以对其进行注释：

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

出于某种原因，英语是通用语/最低公分母。即使从概念上讲，该原因与“每个人都做”一样脆弱，但这仍然是一个相当重要的原因。

违反常规做法意味着您必须了解荷兰语才能理解软件中的数据结构。荷兰语并没有错，但是任何必须与代码库进行交互的工程师说出来的概率仍然低于英语。

因此，除非你是荷兰唯一的商店，并且不打算拓展国际市场曾经，它几乎总是一个好主意，让你的代码和英语，并使用最流行的编码语言。

注意：此建议仅适用于程序代码。用户数据绝对不应翻译，而应按原样进行处理。即使您有客户“ Goldstein”，显然也不应将其名称存储为“金石”。

问题在于“用户提供的，请勿触摸”和“代码片段，始终使用英语”之间存在连续的术语。客户名称非常接近频谱的前端，Java变量接近后端。enum值的常数稍远一些，特别是如果它们表示众所周知的唯一外部实体（例如您的部门），则尤其如此。如果您组织中的每个人都对部门使用荷兰语术语，则您不打算与没有代码库的人打交道，并且现有部门的集合很少发生变化，那么使用可接受的部门名称可能会带来更多枚举常量比局部变量有意义。不过，我仍然不会这样做。

尽可能避免翻译，因为每次翻译都是额外的工作，并且可能会引入错误。

“域驱动设计”对现代软件工程的关键贡献是通用语言的概念，该语言是项目所有利益相关者使用的一种语言。根据DDD的说法，翻译不应该在团队内部（包括领域专家，即使仅通过规范文档的代理人出现）也不能在团队内部进行翻译（进一步阅读：Eric Evans的“域驱动设计”，尤其是各章）关于无处不在的语言和策略设计）。

也就是说，如果您的业务专家（或您的规范文档）说荷兰语，则在源代码中表达业务问题时，请使用其（荷兰语）术语。不要不必要地翻译成英文，因为这样做会给业务专家和程序员之间的交流造成人为的障碍，这会花费时间并且可能（通过歧义或错误的翻译）导致错误。

相比之下，如果您的业务专家可以用英语和荷兰语来谈论他们的业务，那么您就可以选择该项目的普遍语言，这是一种幸运的情况，并且有一些偏爱英语的正当理由（例如“国际上可以理解和更有可能被标准所使用”），但这样做并不意味着编码人员应翻译商务人士正在谈论的内容。相反，商务人士应切换语言。

如果需求很复杂并且必须精确地实现，那么拥有无处不在的语言就显得尤为重要，如果您只是在进行CRUD，那么内部使用的语言就没有那么重要了。

个人轶事：我在一个项目中，我们将一些业务服务公开为SOAP端点。该业务完全用德语指定，因此不太可能像英语一样重复使用，因为它涉及特定司法辖区的法律事务。但是，一些象牙塔建筑师要求SOAP接口为英语，以促进将来的重用。这种翻译是临时发生的，在开发人员之间几乎没有协调，而只是一个共享的词汇表，导致同一业务术语在Web服务合同中具有多个名称，而某些业务术语在Web服务合同中具有相同的名称。哦，当然，在分隔线的任何一边都使用了一些名称-但含义不同！

如果您仍然选择翻译，请在词汇表中将翻译标准化，在您的完成定义中添加符合该词汇表的内容，然后在评论中进行检查。不要像我们以前那样粗心。

正确的解决方案是根本不对部门进行硬编码：

ArrayList<String> departments = (... load them from a configuration file ...)

或者，如果您绝对需要部门类型：

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

如果发现需要对代码中的特定部门进行测试，则必须更一般地询问该部门的特殊之处，并接受将该部门配置为具有该属性。例如，如果一个部门有每周的工资单，而这正是代码所关心的，那么应该有一个WEEKLY_PAYROLL属性，该属性可以通过配置附加到任何部门。

对于任何想知道的人：我们选择了第一个选项，主要是因为我们认为您不应该为了翻译而编造术语。但是，如果某个时候有国际开发人员来从事该项目，我们会添加一些文档来说明：

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

如果您担心要使用字符串表示形式来显示用户或其他内容，只需在枚举内部定义一个descriptions数组并公开一个方法。
例如：Department.BUILD.getDescription();将输出“ BOUW”

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

我知道您选择了其他方式，但以防万一Google涡流意外将人们扔到了这里。

编辑：如Pokechu22所述，您可以使用枚举构造函数和私有属性，如下所示：

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

这也将达到这种效果。

您的代码的某些不变量应保持不变。这些不变量之一是重命名标识符时程序的行为不会有所不同。特别是在这种情况下，当您拥有一个枚举并重命名该枚举的任何成员并更新该成员的所有用法时，您不会期望代码开始以不同的方式运行。

解析是读取数据并从中获取数据结构的过程。当您获取外部数据，读取它并创建枚举的实例时，您正在解析数据。该解析过程是程序的唯一部分，负责维护数据表示形式的接收方式与数据类型成员的形状和命名之间的关系。

因此，为枚举成员分配什么名称都没有关系。它们恰好与您读取的数据中使用的字符串一致是偶然的。

当您设计用于对域建模的代码时，成员名称不应与数据的序列化格式相关。它们既不应该是荷兰语术语，也不应该是荷兰语术语的翻译，但它们应该是您认为最适合领域模型的内容。

解析器然后在数据格式和域模型之间转换。那是数据格式应该对您的代码产生的最后影响。