Traduzindo dados externos para o idioma em que você está programando

Nesse cenário, eu deixaria os valores enum em holandês:

public enum Department { BOUW, ONDERHOUD }

Porque a lógica que usa essas constantes estará combinando com os dados que também estão em holandês . Por exemplo, se a entrada for "bouw", o código de comparação poderá ser semelhante:

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

Acho mais fácil depurar quando os valores correspondem (mesmo que eu não saiba o que significam os valores). Tradução apenas adiciona um aro mental que eu, como desenvolvedor, não deveria ter que pular para provar a correção.

No entanto, você pode apenas comentar o código se ele ajudar os outros a entender o contexto dos dados:

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

O inglês é uma lingua franca / menor denominador comum por um motivo. Mesmo que a razão seja conceitualmente tão fraca quanto "Todo mundo faz isso", essa ainda é uma razão bastante importante.

Ir contra a prática comum significa que você precisa entender o holandês para entender as estruturas de dados em seu software. Não há nada de errado com o holandês, mas a probabilidade de que qualquer engenheiro que tenha que interagir com a base de código fale ainda é menor do que para o inglês.

Portanto, a menos que você seja uma loja só de holandeses e não pretenda expandir internacionalmente ever , é quase sempre uma boa ideia manter sua base de código monolíngue e usar a codificação mais popular idioma.

Nota: Este aviso aplica-se apenas ao código do programa . Os dados do usuário definitivamente não devem ser traduzidos, mas processados "como estão". Mesmo se você tem um cliente "Goldstein", claramente você não deve armazenar seu nome como "pedra de ouro".

O problema é que há um continuum de termos entre "fornecido pelo usuário, não toque" e "fragmento de código, use o inglês o tempo todo". Nomes de clientes estão muito próximos do primeiro extremo do espectro, variáveis Java próximas ao final. Constantes para valores de enum estão um pouco mais distantes, especialmente se denotar entidades externas exclusivas e conhecidas (como seus departamentos). Se todos na sua organização usarem os termos holandeses para os departamentos, você não planeja confrontar ninguém com a base de código que não tem, e o conjunto de departamentos existentes muda raramente, então usar os nomes aceitos do departamento pode fazer mais sentido para constantes enum do que para variáveis locais. Eu ainda não faria isso, no entanto.

Evite a tradução sempre que possível, porque cada tradução é um esforço adicional e pode introduzir erros.

A principal contribuição de "Domain Driven Design" para a engenharia de software moderna é o conceito de uma Linguagem Ubíqua , que é uma única língua usada por todas as partes interessadas de um projeto. De acordo com DDD, a tradução não deve ocorrer dentro de uma equipe (que inclui especialistas de domínio, mesmo se presente apenas por um documento de especificação), mas apenas entre equipes (leitura adicional: "Domain Driven Design" por Eric Evans, em particular os capítulos sobre a linguagem ubíqua e o design estratégico).

Ou seja, se seus especialistas em negócios (ou seu documento de especificação) falam holandês, use sua terminologia (holandesa) ao expressar preocupações de negócios no código-fonte. Não traduza desnecessariamente para o inglês, pois isso cria um impedimento artificial para a comunicação entre especialistas em negócios e programadores, o que leva tempo e pode (por meio de uma tradução ambígua ou incorreta) causar bugs.

Se, por outro lado, seus especialistas em negócios puderem falar sobre seus negócios em inglês e holandês, você terá a sorte de escolher o idioma onipresente do projeto, e há motivos válidos para preferir inglês (como " internacionalmente compreensível e mais provável de ser usado pelos padrões "), mas isso não significa que os programadores devem traduzir o que os empresários estão falando. Em vez disso, os empresários devem mudar de idioma.

Ter uma linguagem onipresente é particularmente importante se os requisitos são complexos e devem ser implementados com precisão, se você estiver apenas fazendo CRUD, a linguagem que você usa internamente é menos importante.

Anedota pessoal: Eu estava em um projeto onde expusemos alguns serviços de negócios como um ponto de extremidade SOAP. O negócio era inteiramente especificado em alemão e provavelmente não seria reutilizado como em inglês, porque se tratava de questões legais específicas de uma determinada jurisdição. No entanto, alguns arquitetos de torre de marfim determinaram que a interface SOAP fosse inglesa para promover a reutilização futura. Essa tradução ocorreu em hoc e com pouca coordenação entre os desenvolvedores, mas apenas um glossário compartilhado, resultando no mesmo termo comercial com vários nomes no contrato de serviço da web e alguns termos comerciais com o mesmo nome no contrato de serviço da web. Ah, e é claro, alguns nomes usados em ambos os lados da divisão - mas com significados diferentes!

Se você optar por traduzir de qualquer maneira, padronize a tradução em um glossário, adicione a conformidade com esse glossário à sua definição de concluído e verifique em seus comentários. Não seja tão descuidado como nós fomos.

A solução correta é não codificar os departamentos:

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

Ou, se você precisar de um tipo de departamento:

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

Se você achar necessário testar em departamentos específicos em seu código, precisará perguntar mais genericamente o que é especial sobre esse departamento e aceitar a configuração desse departamento como tendo essa propriedade. Por exemplo, se um departamento tiver folha de pagamento semanal, e é com isso que o código se preocupa, deve haver uma propriedade WEEKLY_PAYROLL que pode ser anexada a qualquer departamento pela configuração.

Para qualquer pessoa que esteja se perguntando: escolhemos a primeira opção, principalmente porque achamos que você não deve criar termos para traduzir. No entanto, se algum dia, um desenvolvedor internacional estiver trabalhando no projeto, adicionamos alguma documentação para explicá-lo:

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

Se você estiver preocupado em ter uma representação de string para mostrar o usuário ou algo assim, apenas defina um array de descrições dentro de seu enum e exponha um método.
Por exemplo: Department.BUILD.getDescription(); produzirá "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Eu sei que você escolheu o contrário, mas apenas no caso de o vórtice do Google jogar as pessoas aqui por acidente.

EDIT: Como observado por Pokechu22 , você pode usar construtores de enumeração e propriedades particulares como esta:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

que também atingirá esse efeito.

Certos invariantes de seu código devem ser mantidos. Uma dessas invariantes é que um programa não se comportará de maneira diferente quando um identificador for renomeado. Nesse caso em particular, quando você tem um enum, renomeia qualquer membro desse enum e atualiza todos os usos desse membro, você não esperaria que seu código começasse a funcionar de maneira diferente.

A análise é o processo de leitura de dados e derivação de estruturas de dados a partir dela. Quando você pega os dados externos, lê e cria instâncias do seu enum, você está analisando os dados. Esse processo de análise é a única parte do seu programa responsável por manter a relação entre a representação de dados como você a recebe e a forma e nomeação dos membros dos seus tipos de dados.

Como tal, não importa quais nomes você atribui aos membros do enum. O fato de coincidirem com as strings usadas nos dados que você lê é uma coincidência.

Quando você cria seu código para modelar o domínio, os nomes dos membros não devem estar relacionados ao formato de serialização dos dados. Eles não devem ser os termos holandeses, nem devem ser traduções dos termos holandeses, mas devem ser o que você decidir se encaixa melhor no modelo de domínio.

O analisador é o que traduz entre o formato de dados e seu modelo de domínio. Essa é a última influência que o formato de dados deve ter no seu código.