Eu sei que já existem algumas perguntas que estão intimamente relacionadas a esse assunto, mas nenhuma delas toma a Linguagem Ubíqua como ponto de partida, por isso acho que justifica essa pergunta.
Para quem não sabe: Linguagem Ubíqua é o conceito de definir uma linguagem (falada e escrita) que é usada igualmente entre desenvolvedores e especialistas em domínio para evitar inconsistências e falta de comunicação devido a problemas de tradução e mal-entendidos. Você verá a mesma terminologia exibida no código, nas conversas entre qualquer membro da equipe, nas especificações funcionais e outros enfeites.
Então, o que eu queria saber é como lidar com o idioma ubíquo em domínios que não sejam o inglês.
Pessoalmente, sou a favor de escrever completamente o código de programação em inglês, incluindo comentários, mas é claro, excluindo constantes e recursos.
No entanto, em um domínio que não seja o inglês, sou obrigado a tomar uma decisão:
- Escreva um código que reflita o idioma ubíquo no idioma natural do domínio.
- Traduza o idioma ubíquo para o inglês e pare de se comunicar no idioma natural do domínio.
- Defina uma tabela que define como o idioma ubíquo se traduz em inglês.
Aqui estão alguns dos meus pensamentos com base nessas opções:
1) Tenho uma forte aversão ao código de idioma misto, que é codificado usando nomes de tipo / membro / variável etc. que não são do inglês. A maioria das linguagens de programação 'respira' inglês em grande parte e a maioria da literatura técnica, nomes de padrões de design etc. também está em inglês. Portanto, na maioria dos casos, não há como escrever código inteiramente em um idioma que não seja o inglês, então você acaba com idiomas mistos.
2) Isso forçará os especialistas em domínio a começar a pensar e falar no equivalente em inglês da UL, algo que provavelmente não virá naturalmente para eles e, portanto, dificultará significativamente a comunicação.
3) Nesse caso, os desenvolvedores se comunicam com os especialistas em domínio em seu idioma nativo, enquanto os desenvolvedores se comunicam em inglês e, o mais importante, escrevem código usando a tradução em inglês do UL.
Tenho certeza de que não quero ir para a primeira opção e acho que a opção 3 é muito melhor que a opção 2. O que você acha? Estou faltando outras opções?
ATUALIZAR
Hoje, cerca de um ano depois, tendo lidado com essa questão diariamente, devo dizer que a opção 3 funcionou muito bem para mim.
Não era tão tedioso quanto eu inicialmente temia e traduzir em tempo real enquanto conversava com o cliente também não era um problema.
Também achei as seguintes vantagens verdadeiras, com base na minha experiência.
- A tradução do UL faz com que você preste mais atenção na definição do UL e até do próprio domínio, especialmente quando você não sabe traduzir um termo e precisa começar a procurar nos dicionários etc. Isso me levou a reconsiderar as decisões de modelagem de domínio algumas vezes.
- Isso ajuda você a aprofundar seu conhecimento do idioma inglês.
- Obviamente, seu código é muito mais agradável de se ver, em vez de ser uma obscenidade incompreensível.
fonte
Respostas:
Eu já enfrentei esse problema com frequência e, na minha opinião, a resposta é: "não existe uma resposta única válida para todos os cenários".
Mas lembre-se de que a linguagem ubíqua não é um objetivo em si. É uma ferramenta para reforçar a comunicação entre a equipe e os Especialistas em Domínio e reforçar a coerência conceitual do modelo implementado em código, testes e conversação.
Se você pode falar UL sem ambiguidade, está no caminho certo. Se você e seus colegas estão traduzindo continuamente de código para conversa ou de conceito para conceito, provavelmente está fora do caminho.
Na prática, nem todos os domínios são iguais, nem especialistas em domínios. De qualquer forma, alguns domínios têm muita terminologia em inglês (domínios com tecnologia, por exemplo) e parece razoável optar por uma opção em inglês completo. No entanto, algumas culturas podem influenciar essa escolha (o francês vem à mente) e a difusão da terminologia inglesa varia de país para país. Em alguns outros domínios (Jurídico, para citar um), não há como traduzir alguns termos. Ou a tradução tornaria absolutamente mais difícil para o Especialista em Domínio acompanhar a conversa.
Em geral, estamos mais interessados no que o especialista em domínio tem a dizer. Então, queremos facilitar as coisas para eles. Caso contrário, eles poderiam simplesmente fazer uma aula UML e ler nossos diagramas (isso era uma piada). Portanto, a única recomendação real aqui é: "preste atenção ao comportamento do especialista em domínio", se eles estiverem envolvidos na conversa e a conversa continuar sem problemas, você provavelmente estará no caminho certo, mantenha esse idioma. Pode causar um pouco de trabalho extra na equipe, mas tudo bem. Como desenvolvedores, somos um pouco treinados para aprender palavras com significado específico em um contexto.
Estranhamente, essa pergunta sempre é acompanhada pela suposição de que todo o código precisa falar um idioma. Isso também pode ser desafiado. Eu não sou um inglês nativo e o conhecimento de uma língua estrangeira não é chato: meu cérebro acelera ao falar sobre nome , sobrenome , carro e coisas do tipo, perde alguns detalhes ao falar sobre CEP , diminui a velocidade ao falar sobre empréstimo e definitivamente pergunta para uma explicação tranquilizadora ao falar sobre hipotecas .
Então, novamente, escolha a melhor combinação que fará com que a conversa principal flua e forneça a maior quantidade de informações e comentários do Especialista em Domínio.
fonte
Normalmente, considero certas palavras técnicas neutras quanto ao idioma, mesmo que haja uma tradução no outro idioma.
Por exemplo, ao falar sobre codificação em alemão, ainda uso o vocabulário técnico em inglês como se fossem palavras em alemão, mesmo que exista um equivalente em alemão.
No seu caso, eu faria o oposto. Importe certas palavras técnicas da sua língua nativa para o inglês, assim como as palavras estrangeiras foram importadas há séculos. Faça com que eles se comportem gramaticalmente como palavras em inglês. Parece estranho no começo, mas você vai se acostumar.
fonte
Concordo com o comentário em inglês 'respirar' da maioria das linguagens de programação , que sempre se torna um problema com os esforços de desenvolvimento em vários idiomas
Normalmente eu teria o UL no idioma da sua equipe de programação
O que fizemos no passado é criar novas palavras que expressem melhor os tópicos do domínio. Em um projeto em francês / inglês, as palavras inventadas são baseadas principalmente em inglês, mas com sabor francês (não muito difíceis, pois muitas palavras em inglês são francesas de qualquer maneira), mas isso pode se aplicar a qualquer mix de idiomas
por exemplo
Em inglês, é "Quantidade de madeira" ou "quantidade de madeira"; em francês, é "quanté de bois"; portanto, é suficientemente próximo para os dois alto-falantes. Isso deve reduzir a quantidade de novas palavras que cada palestrante precisa aprender
Qual é o tamanho do seu domínio UL? Isso se torna o problema. Se tiver menos de 100 frases-chave, você poderá usar uma linguagem de estilo híbrida, se maior, eu manteria a linguagem predominante dos desenvolvedores, pois eles geralmente precisam lidar com isso mais intensamente.
Publique um dicionário / tesauro wiki para que todos possam fazer referência também, conforme necessário, para que não haja desculpas para compreensão
fonte
Recentemente, trabalhei em um projeto DDD na Suíça, onde o domínio era impostos (especificamente IVA e outro tipo de imposto ... que não é facilmente traduzível para inglês ...).
Eles escolheram a primeira opção: UL em alemão, usado também no código em alemão.
Antes de trabalhar neste projeto, eu tinha exatamente a mesma aversão que você para código de idioma misto. Eu (ainda) gosto de ter tudo em inglês, embora não seja um falante nativo de inglês. Eu também não sou um falante nativo de alemão. Então, quando comecei a explorar a base de código, fiquei horrorizada.
Depois de um ano trabalhando nesse projeto, devo admitir que acho que foi a decisão certa nesse caso (também poderíamos ter usado o francês ou o italiano, os outros idiomas oficiais da Suíça, mas a maioria dos atores do projeto era alemão nativo caixas de som).
Muitos dos termos específicos do domínio não eram realmente traduzíveis para o inglês de maneira significativa. De qualquer maneira, tive que aprender os termos em alemão para me comunicar com o resto da equipe. Teria sido mais confuso ter que aprender também traduções para o inglês, que teriam sido inventadas do nada.
Então eu acho que realmente depende do domínio. Alguns domínios serão realmente difíceis de traduzir para o inglês e não fará muito sentido.
Provavelmente também depende da língua nativa. O alemão é um idioma em que você pode compor palavras aproximadamente da mesma maneira e principalmente da mesma ordem que em inglês. Por exemplo, uma declaração de imposto seria uma declaração de Steuerdek . Não é chocantemente diferente.
Não sei como criaria um nome de classe equivalente em francês, por exemplo, se o termo natural fosse "déclaration d'impôts", com a ordem oposta e uma preposição extra no meio ... E isso é apenas um exemplo simples. Eu ficaria realmente interessado se alguém tiver experiência com esse tipo de nomeação em idiomas latinos (francês, espanhol, italiano, português ...)!
Outro desafio foram as formas plurais, que em alemão às vezes dificilmente se distinguem do singular (enquanto em inglês quase sempre tem um s no final).
Os caracteres acentuados foram bons, pois em alemão todos eles têm um equivalente não acentuado ( ü -> ue e assim por diante). É outro ponto em que os franceses seriam mais problemáticos ...
fonte