영어 이외의 도메인에서 프로그래밍 및 유비쿼터스 언어 (DDD)


64

나는 여기에 이미이 주제와 밀접한 관련이있는 몇 가지 질문이 있지만 Ubiquitous Language 를 시작점으로 사용하는 질문은 아무도 없으므로이 질문을 정당화한다고 생각합니다.

모르는 사람들을 위해 : 유비쿼터스 언어는 번역 문제와 오해로 인한 불일치와 잘못된 의사 소통을 피하기 위해 개발자와 도메인 전문가가 똑같이 사용하는 (말하고 쓰는) 언어를 정의하는 개념입니다. 코드, 팀원 간의 대화, 기능 사양 및 기타 사항에 동일한 용어가 표시됩니다.

그래서 제가 궁금한 것은 영어 이외의 도메인에서 유비쿼터스 언어를 다루는 방법입니다.

개인적으로, 나는 주석을 포함하여 물론 프로그래밍과 상수를 제외한 모든 프로그래밍 코드를 영어로 작성하는 것이 좋습니다.

그러나 영어 이외의 도메인에서는 다음 중 하나를 결정해야합니다.

  1. 도메인의 자연 언어로 유비쿼터스 언어를 반영하는 코드를 작성하십시오.
  2. 유비쿼터스 언어를 영어로 번역하고 도메인의 자연어 통신을 중단하십시오.
  3. 유비쿼터스 언어가 영어로 번역되는 방식을 정의하는 테이블을 정의하십시오.

다음은 이러한 옵션에 대한 내 생각 중 일부입니다.

1) 영어가 아닌 유형 / 멤버 / 변수 이름 등을 사용하여 코딩하는 혼합 언어 코드에 대한 강력한 혐오가 있습니다. 대부분의 프로그래밍 언어는 대부분 영어를 '호흡'하며 대부분의 기술 문헌, 디자인 패턴 이름 등은 영어로되어 있습니다. 따라서 대부분의 경우 영어 이외의 언어로 코드를 작성하는 방법이 없으므로 혼합 언어로 끝납니다.

2) 이것은 도메인 전문가들이 UL과 동등한 영어로 사고하고 말하기 시작하도록 강제 할 것입니다. 이는 아마도 그들에게 자연스럽게 오지 않을 것이므로 의사 소통을 크게 방해합니다.

3)이 경우 개발자는 모국어로 도메인 전문가와 의사 소통하는 반면 개발자는 영어로 서로 의사 소통하며 가장 중요하게는 UL의 영어 번역을 사용하여 코드를 작성합니다.

첫 번째 옵션으로 가고 싶지 않다고 확신하고 옵션 3이 옵션 2보다 훨씬 낫다고 생각합니다. 어떻게 생각하십니까? 다른 옵션이 없습니까?

최신 정보

약 1 년 후인 오늘,이 문제를 매일 다루면서 옵션 3이 제게 잘 작동했다고 말해야합니다.

내가 처음에 두려워하고 실시간으로 번역하는 것은 고객과 대화하는 것이 문제가 아니기 때문에 지루하지 않았습니다.

또한 내 경험을 바탕으로 다음과 같은 장점이 있음을 알았습니다.

  • UL을 번역하면 특히 용어를 번역하는 방법을 모르고 사전 등을 살펴보아야 할 때 UL 및 도메인 자체를 정의하는 데 더 많은주의를 기울일 수 있습니다. 이로 인해 도메인 모델링 결정을 재고해야했습니다. 몇 번.
  • 그것은 당신이 영어에 대한 지식을 더 깊이 이해할 수 있도록 도와줍니다.
  • 분명히, 당신의 코드는 외설스러워하는 마음 대신에 보는 것이 훨씬 즐겁습니다.

9
특별한 질문 +1. 우리는 많은 유비쿼터스 언어 개발을하고 있으며 이것은 우리에게 큰 문제입니다. 좋은 답변을 기대합니다!
CesarGon 2012 년

2
당신의 분석은 완벽하다고 생각합니다. 다른 프로젝트 시나리오에 크게 의존하기 때문에이 주제에 대한 대답을하기는 어렵습니다. 예를 들어, 법률 회사를위한 소프트웨어를 개발하는 경우 개발자이므로 모든 단어를 번역하는 방법을 모르기 때문에 코드에서 영어로 모든 단어를 사용하기가 어려울 수 있습니다. 옵션 1) 때로는 대답이 있습니다.
Alex

저는 올해 벨기에에서 일을 시작하려고했지만 그 생각조차하지 않았습니다. 그들이 어떤 경로를 택했는지는“흥미로운”것이 될 것입니다. 특히 내가 인도의 일부를 아웃소싱했다고 들었을 때 특히 그렇습니다.
Phil N DeBlanc

업데이트에 대한 훌륭한 질문과 감사-또한 옵션 3을 선호하며 확인을 매우 기쁘게 생각합니다.
lutzh

답변:


11

저는이 문제에 자주 직면했으며 제 생각에는 "모든 시나리오에 유효한 단일 답변은 없습니다"라고 대답합니다.

그러나 유비쿼터스 언어는 그 자체가 목표가 아님을 명심하십시오. 팀과 도메인 전문가 간의 의사 소통을 강화하고 코드, 테스트 및 대화에서 구현 된 모델의 개념적 일관성을 유지하는 도구입니다.

확실하게 UL을 말할 수 있다면 올바른 길을 가고있는 것입니다. 당신과 당신의 동료들이 코드에서 대화로 또는 개념에서 개념으로 지속적으로 번역한다면, 아마 당신은 아마 틀렸을 것입니다.

실제로 모든 도메인이 동일하거나 도메인 전문가는 아닙니다. 어쨌든 일부 도메인에는 많은 영어 용어 (예 : 기술 중심 도메인)가 있으며 전체 영어 선택을 선택하는 것이 합리적입니다. 그러나 일부 문화권은이 선택에 영향을 줄 수 있으며 (프랑스어가 떠오름) 영어 용어의 확산은 국가마다 다릅니다. 일부 다른 도메인 (법률, 이름 지정)에서는 일부 용어를 번역 할 방법이 없습니다. 또는 번역하면 도메인 전문가가 대화를 따르는 것이 절대적으로 어려워집니다.

일반적으로 도메인 전문가의 의견에 더 관심이 있습니다. 그래서 우리는 그것들을 쉽게 만들려고합니다. 그렇지 않으면 UML 클래스를 가져 와서 다이어그램을 읽을 수 있습니다 (농담이었습니다). "도메인 전문가 행동에주의를 기울여야합니다."대화에 참여하고 대화가 순조롭게 진행되는 경우에는 해당 언어를 그대로 유지 하는 것 입니다. 팀에 약간의 추가 작업이 발생할 수 있지만 괜찮습니다. 개발자로서 우리는 문맥에서 특정한 의미를 가진 단어를 배우도록 다소 훈련되었습니다.

이상하게도이 질문에는 항상 모든 코드가 한 언어를 사용해야한다는 가정이 수반됩니다. 그것도 도전받을 수 있습니다. 나는 모국어가 아니며 외국어에 대한 지식이 평평하지 않습니다. 이름 , , 자동차 등에 대해 이야기 할 때 뇌가 빨리 가고 , 우편 번호 에 대해 이야기 할 때 세부 사항이 누락되고, 대출 에 대해 이야기 할 때 속도가 느려지고 확실히 묻습니다. 모기지 에 관해 이야기 할 때 안심할 수있는 설명을 위해 .

따라서 주요 대화 흐름을 만들고 도메인 전문가의 정보와 피드백을 최대한 제공 할 수있는 최상의 조합을 다시 선택하십시오.


1
음, 우편 번호는 일반적인 영어 단어 (즉 것이 아니다 우편 번호 ). 우편 번호는 미국 우편 서비스에 따라 다릅니다.
TRiG

1
수정 해 주셔서 감사합니다. ...이 아마 내가 ;-) 실종 세부 사항 중 하나입니다
ZioBrando

4

나는 보통 다른 언어로 번역 된 경우에도 특정 기술 단어를 언어 중립으로 간주합니다.

예를 들어, 독일어로 코딩하는 것에 대해 이야기 할 때, 독일어에 해당하는 단어가 있더라도 영어 단어는 마치 독일어 단어 인 것처럼 사용합니다.

귀하의 경우 나는 반대를 할 것입니다. 수세기 동안 외국어를 가져온 것처럼 특정 기술 단어를 모국어에서 영어로 가져옵니다. 영어 단어처럼 문법적으로 동작하게하십시오. 처음에는 이상하게 느껴지지만 익숙해집니다.


1
그것은 내가 팀의 일을 논의한 것을 들었던 팀장을 생각 나게한다. 이것은 폴란드 노동자들과 함께 노르웨이였습니다. 모든 영어를 구사하지만 건설 및 도구와 관련된 대부분의 단어는 노르웨이어였습니다. 어리석게 들렸지 만 잘 전달되었습니다.
Grastveit

3

나는 항상 다국어 개발 노력의 문제가되는 대부분의 프로그래밍 언어 '호흡'영어 의견에 동의합니다.

일반적으로 프로그래밍 팀 언어로 UL을 사용합니다.

우리가 과거에 한 일은 도메인 주제를 더 잘 표현할 수있는 새로운 단어를 만드는 것입니다. 프랑스어 / 영어 프로젝트에서는 주로 영어 기반이지만 프랑스어 풍미 (어쨌든 많은 영어 단어가 프랑스어 인 것처럼 어렵지 않음)로 구성된 단어를 구성하지만 이는 모든 언어 혼합에 적용될 수 있습니다.

예 :

"수량 부아"

영어에서는 "나무의 양"또는 "나무의 양", 프랑스어의 경우 "quantité de bois"이므로 두 스피커 모두에 가깝습니다. 이것은 각 화자가 배울 새로운 단어의 양을 줄여야합니다

귀하의 도메인 UL은 얼마나 큽니까? 이것이 문제가됩니다. 핵심 문구가 100 개 미만인 경우 하이브리드 구성 스타일 언어를 사용할 수 있습니다. 더 크면 일반적으로 개발자가 더 강렬하게 처리해야하므로 개발자의 주된 언어를 고수합니다.

모든 사람이 필요에 따라 참조 할 수 있도록 Wiki 사전 / 동의어 사전 게시


3

나는 최근 스위스의 DDD 프로젝트에서 일했으며, 도메인은 세금이었습니다 (특히 VAT 및 다른 종류의 세금 ... 영어로 쉽게 번역 할 수는 없습니다 ...).

그들은 첫 번째 옵션을 선택했습니다 : 독일어의 UL, 독일어의 코드에도 사용되었습니다.

이 프로젝트를 수행하기 전에 혼합 언어 코드에 대해 똑같은 혐오감을 가졌습니다. 나는 영어를 모국어로 사용하지는 않지만 영어로 모든 것을 갖고 싶어합니다. 나는 또한 독일어 원어민이 아닙니다. 그래서 코드베이스를 탐색하기 시작했을 때 나는 충격을 받았습니다.

이 프로젝트에서 일한 지 1 년이 지난 지금이 ​​결정이 옳은 결정이라고 생각해야합니다 (우리는 프랑스어 또는 이탈리아어, 다른 공식 스위스 언어를 사용할 수도 있었지만 프로젝트의 대부분의 배우는 네이티브 독일어였습니다) 스피커).

도메인의 많은 특정 용어는 실제로 의미있는 방식으로 영어로 번역 할 수 없었습니다. 어쨌든 팀의 다른 팀과 의사 소통하기 위해 독일어 용어를 배워야했습니다. 어쨌든 얇은 공중에서 발명 된 영어 번역을 배워야한다는 것은 더 지저분 할 것입니다.

그래서 그것은 실제로 도메인에 달려 있다고 생각합니다. 일부 도메인은 영어로 번역하기가 매우 어려워서 의미가 없습니다.

아마도 모국어에도 의존 할 것입니다. 독일어는 거의 영어와 같은 방식으로, 특히 같은 순서로 단어를 작성할 수있는 언어입니다. 예를 들어 세금 신고Steuerdeklaration 입니다. 놀랍게도 다르지 않습니다.

예를 들어, 프랑스어로 동등한 클래스 이름을 만드는 방법을 모르겠습니다. 예를 들어 중간 용어는 반대 순서와 여분의 전치사와 함께 자연어 용어 "déclaration d' impôts"였습니다. 간단한 예입니다. 라틴어 (프랑스어, 스페인어, 이탈리아어, 포르투갈어 ...)로 그러한 종류의 명명에 경험이있는 사람이 있다면 정말 흥미로울 것입니다!

또 다른 도전은 복수형으로, 독일어에서는 단수형과 거의 구별하기 어려운 경우가 있습니다 (영어로는 거의 항상 끝에 s 가 있습니다).

강조된 문자는 괜찮습니다. 독일어에서는 모두 강조되지 않은 문자 ( ü- > ue 등)가 있기 때문입니다. 프랑스가 더 문제가 될 수있는 또 다른 지점입니다 ...

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.