Programación y lenguaje ubicuo (DDD) en un dominio que no es inglés

Sé que ya hay algunas preguntas que están estrechamente relacionadas con este tema, pero ninguna de ellas toma el lenguaje ubicuo como punto de partida, así que creo que eso justifica esta pregunta.

Para aquellos que no saben: el lenguaje ubicuo es el concepto de definir un lenguaje (tanto hablado como escrito) que se use por igual entre los desarrolladores y expertos en dominios para evitar inconsistencias y problemas de comunicación debido a problemas de traducción y malentendidos. Verá la misma terminología en código, conversaciones entre cualquier miembro del equipo, especificaciones funcionales y demás.

Entonces, lo que me preguntaba es cómo tratar el lenguaje ubicuo en dominios que no están en inglés.

Personalmente, estoy totalmente a favor de escribir completamente el código de programación en inglés, incluidos los comentarios, pero por supuesto excluyendo las constantes y los recursos.

Sin embargo, en un dominio que no es inglés, me veo obligado a tomar una decisión:

1. Escriba código que refleje el Idioma ubicuo en el lenguaje natural del dominio.
2. Traduce el idioma ubicuo al inglés y deja de comunicarte en el idioma natural del dominio.
3. Defina una tabla que defina cómo se traduce el idioma ubicuo al inglés.

Estos son algunos de mis pensamientos basados ​​en estas opciones:

1) Tengo una fuerte aversión contra el código de lenguaje mixto, que es la codificación usando nombres de tipo / miembro / variable, etc., que no están en inglés. La mayoría de los lenguajes de programación 'respiran' el inglés en gran medida y la mayoría de la literatura técnica, los nombres de los patrones de diseño, etc., también están en inglés. Por lo tanto, en la mayoría de los casos simplemente no hay forma de escribir código completamente en un idioma que no sea inglés, por lo que terminas con idiomas mixtos de todos modos.

2) Esto obligará a los expertos en el dominio a comenzar a pensar y hablar en el equivalente en inglés del UL, algo que probablemente no les resultará natural y, por lo tanto, dificulta la comunicación de manera significativa.

3) En este caso, los desarrolladores se comunican con los expertos del dominio en su idioma nativo, mientras que los desarrolladores se comunican entre sí en inglés y, lo que es más importante, escriben código utilizando la traducción al inglés de la UL.

Estoy seguro de que no quiero ir a la primera opción y creo que la opción 3 es mucho mejor que la opción 2. ¿Qué opinas? ¿Me faltan otras opciones?

ACTUALIZAR

Hoy, aproximadamente un año después, después de haber tratado este problema a diario, debo decir que la opción 3 me ha funcionado bastante bien.

No fue tan tedioso como temía inicialmente y traducirlo en tiempo real mientras hablaba con el cliente tampoco fue un problema.

También descubrí que las siguientes ventajas son ciertas, según mi experiencia.

• La traducción de la UL hace que preste más atención a la definición de la UL e incluso del dominio mismo, especialmente cuando no sabe cómo traducir un término y tiene que comenzar a buscar en los diccionarios, etc. Esto incluso me ha llevado a reconsiderar las decisiones de modelado de dominio unas pocas veces.
• Le ayuda a profundizar su conocimiento del idioma inglés.
• Obviamente, su código es mucho más agradable de ver en lugar de ser una obscenidad alucinante.

Me he enfrentado a este problema con frecuencia y, en mi opinión, la respuesta es: "no hay una respuesta única válida para todos los escenarios".

Pero tenga en cuenta que el lenguaje ubicuo no es un objetivo per se. Es una herramienta para reforzar la comunicación entre el equipo y los Expertos de dominio y para reforzar la coherencia conceptual del modelo implementado en código, pruebas y conversación.

Si puedes hablar UL sin ambigüedades, estás en el camino correcto. Si usted y sus compañeros están traduciendo continuamente de código a conversación o de un concepto a otro, entonces probablemente no estén al día.

En la práctica, no todos los dominios son iguales, ni los expertos en dominios. De todos modos, algunos dominios tienen mucha terminología en inglés (dominios basados ​​en tecnología, por ejemplo) y parece razonable optar por una opción de inglés completo. Sin embargo, algunas culturas pueden influir en esta elección (me viene a la mente el francés) y la difusión de la terminología en inglés varía de un país a otro. En algunos otros dominios (Legal, por nombrar uno) no hay forma de traducir algunos términos. O traducir hará que sea absolutamente más difícil para Expertos de dominio seguir la conversación.

En general, estamos más interesados ​​en lo que dice el experto en dominios. Por eso queremos facilitarles las cosas. De lo contrario, podrían simplemente tomar una clase UML y leer nuestros diagramas (eso fue una broma). Entonces, la única recomendación real aquí es: "preste atención al comportamiento del experto en dominios", si están involucrados en la conversación y la conversación continúa sin problemas, probablemente esté en camino, mantenga ese lenguaje. Puede causar un poco de trabajo extra en el equipo, pero está bien. Como desarrolladores, estamos algo capacitados para aprender palabras con un significado específico en un contexto.

Curiosamente, esta pregunta siempre va acompañada de la suposición de que todo el código necesita hablar un idioma. Eso también podría ser desafiado. No soy un inglés nativo, y el conocimiento de un idioma extranjero no es plano: mi cerebro se acelera cuando hablo de nombre , apellido , automóvil y similares, pierde algunos detalles cuando habla de código postal , disminuye la velocidad cuando habla de préstamo y definitivamente pregunta para una explicación tranquilizadora cuando se habla de hipoteca .

Entonces, una vez más, elija la mejor combinación que haga fluir la conversación clave y proporcione la mayor cantidad de información y comentarios del experto en dominios.

Por lo general, considero ciertas palabras técnicas como lenguaje neutral, incluso si hay una traducción en el otro idioma.

Por ejemplo, cuando hablo de codificación en alemán, sigo usando el vocabulario técnico inglés como si fueran palabras alemanas, incluso si hay un equivalente alemán.

En tu caso, haría lo contrario. Importe ciertas palabras técnicas de su idioma nativo al inglés al igual que las palabras extranjeras se han importado durante siglos. Haz que se comporten gramaticalmente como palabras en inglés. Al principio se siente extraño, pero te acostumbrarás.

Estoy de acuerdo con el comentario en inglés de la mayoría de los lenguajes de programación que siempre se convierte en un problema con los esfuerzos de desarrollo en varios idiomas

Normalmente tendría la UL en el lenguaje de su equipo de programación

Lo que hemos hecho en el pasado es inventar nuevas palabras que expresen mejor los temas del dominio. Con un proyecto francés / inglés, las palabras inventadas se basaban principalmente en inglés pero con sabor francés (no demasiado difícil ya que muchas palabras inglesas son francesas de todos modos), pero esto podría aplicarse a cualquier combinación de idiomas

p.ej

"cantidad bois"

En inglés es "Cantidad de madera" o "cantidad de madera", en francés es "quantité de bois", por lo que está lo suficientemente cerca para ambos hablantes. Esto debería reducir la cantidad de palabras nuevas que cada hablante tiene que aprender

¿Qué tan grande es tu dominio UL? Esto se convierte en el problema. Si tiene menos de 100 frases clave, entonces puede usar un lenguaje de estilo híbrido inventado, si es más grande, pegaría el lenguaje predominante de los desarrolladores, ya que generalmente tienen que tratarlo con más intensidad.

Publique un diccionario wiki / tesauro para que todos lo consulten también, según sea necesario, de modo que no haya excusas para la comprensión

Recientemente trabajé en un proyecto DDD en Suiza, donde el dominio eran los impuestos (específicamente el IVA y otro tipo de impuestos ... que no se puede traducir fácilmente al inglés ...).

Eligieron la primera opción: UL en alemán, utilizada también en el código en alemán.

Antes de trabajar en este proyecto, tenía exactamente la misma aversión que tú por el código de lenguaje mixto. (Todavía) me gusta tener todo en inglés, aunque no soy un hablante nativo de inglés. Tampoco soy un hablante nativo de alemán. Entonces, cuando comencé a explorar la base de código, me horroricé.

Después de un año trabajando en ese proyecto, debo admitir que creo que fue la decisión correcta en este caso (también podríamos haber usado el francés o el italiano, los otros idiomas oficiales suizos, pero la mayoría de los actores en el proyecto eran alemanes nativos) Altavoces).

Muchos de los términos específicos del dominio realmente no se podían traducir al inglés de manera significativa. Tenía que aprender los términos alemanes de todos modos para comunicarme con el resto del equipo. Hubiera sido más complicado tener que aprender también traducciones al inglés, que de todos modos se habrían inventado de la nada.

Así que supongo que realmente depende del dominio. Algunos dominios serán muy difíciles de traducir al inglés y no tendrá mucho sentido.

Probablemente también depende del idioma nativo. El alemán es un idioma donde puedes componer palabras aproximadamente de la misma manera y especialmente en el mismo orden que en inglés. Por ejemplo, una declaración de impuestos sería una Steuerdeklaration . No sorprendentemente diferente.

No sé cómo haría un nombre de clase equivalente en francés, por ejemplo, si el término natural fuera "déclaration d'impôts", con el orden opuesto y una preposición adicional en el medio ... Y eso es solo Un simple ejemplo. ¡Me interesaría mucho si alguien tiene experiencia con ese tipo de nombres en idiomas latinos (francés, español, italiano, portugués ...)!

Otro desafío fueron las formas plurales, que en alemán a veces apenas se distinguen del singular (mientras que en inglés casi siempre tiene una s al final).

Los caracteres acentuados estaban bien, ya que en alemán todos tienen un equivalente no acentuado ( ü -> ue, etc.). Es otro punto donde los franceses serían más problemáticos ...