나는 여기에 이미이 주제와 밀접한 관련이있는 몇 가지 질문이 있지만 Ubiquitous Language 를 시작점으로 사용하는 질문은 아무도 없으므로이 질문을 정당화한다고 생각합니다.
모르는 사람들을 위해 : 유비쿼터스 언어는 번역 문제와 오해로 인한 불일치와 잘못된 의사 소통을 피하기 위해 개발자와 도메인 전문가가 똑같이 사용하는 (말하고 쓰는) 언어를 정의하는 개념입니다. 코드, 팀원 간의 대화, 기능 사양 및 기타 사항에 동일한 용어가 표시됩니다.
그래서 제가 궁금한 것은 영어 이외의 도메인에서 유비쿼터스 언어를 다루는 방법입니다.
개인적으로, 나는 주석을 포함하여 물론 프로그래밍과 상수를 제외한 모든 프로그래밍 코드를 영어로 작성하는 것이 좋습니다.
그러나 영어 이외의 도메인에서는 다음 중 하나를 결정해야합니다.
- 도메인의 자연 언어로 유비쿼터스 언어를 반영하는 코드를 작성하십시오.
- 유비쿼터스 언어를 영어로 번역하고 도메인의 자연어 통신을 중단하십시오.
- 유비쿼터스 언어가 영어로 번역되는 방식을 정의하는 테이블을 정의하십시오.
다음은 이러한 옵션에 대한 내 생각 중 일부입니다.
1) 영어가 아닌 유형 / 멤버 / 변수 이름 등을 사용하여 코딩하는 혼합 언어 코드에 대한 강력한 혐오가 있습니다. 대부분의 프로그래밍 언어는 대부분 영어를 ‘호흡’하며 대부분의 기술 문헌, 디자인 패턴 이름 등은 영어로되어 있습니다. 따라서 대부분의 경우 영어 이외의 언어로 코드를 작성하는 방법이 없으므로 혼합 언어로 끝납니다.
2) 이것은 도메인 전문가들이 UL과 동등한 영어로 사고하고 말하기 시작하도록 강제 할 것입니다. 이는 아마도 그들에게 자연스럽게 오지 않을 것이므로 의사 소통을 크게 방해합니다.
3)이 경우 개발자는 모국어로 도메인 전문가와 의사 소통하는 반면 개발자는 영어로 서로 의사 소통하며 가장 중요하게는 UL의 영어 번역을 사용하여 코드를 작성합니다.
첫 번째 옵션으로 가고 싶지 않다고 확신하고 옵션 3이 옵션 2보다 훨씬 낫다고 생각합니다. 어떻게 생각하십니까? 다른 옵션이 없습니까?
최신 정보
약 1 년 후인 오늘,이 문제를 매일 다루면서 옵션 3이 제게 잘 작동했다고 말해야합니다.
내가 처음에 두려워하고 실시간으로 번역하는 것은 고객과 대화하는 것이 문제가 아니기 때문에 지루하지 않았습니다.
또한 내 경험을 바탕으로 다음과 같은 장점이 있음을 알았습니다.
- UL을 번역하면 특히 용어를 번역하는 방법을 모르고 사전 등을 살펴보아야 할 때 UL 및 도메인 자체를 정의하는 데 더 많은주의를 기울일 수 있습니다. 이로 인해 도메인 모델링 결정을 재고해야했습니다. 몇 번.
- 그것은 당신이 영어에 대한 지식을 더 깊이 이해할 수 있도록 도와줍니다.
- 분명히, 당신의 코드는 외설스러워하는 마음 대신에 보는 것이 훨씬 즐겁습니다.
답변
저는이 문제에 자주 직면했으며 제 생각에는 “모든 시나리오에 유효한 단일 답변은 없습니다”라고 대답합니다.
그러나 유비쿼터스 언어는 그 자체가 목표가 아님을 명심하십시오. 팀과 도메인 전문가 간의 의사 소통을 강화하고 코드, 테스트 및 대화에서 구현 된 모델의 개념적 일관성을 유지하는 도구입니다.
확실하게 UL을 말할 수 있다면 올바른 길을 가고있는 것입니다. 당신과 당신의 동료들이 코드에서 대화로 또는 개념에서 개념으로 지속적으로 번역한다면, 아마 당신은 아마 틀렸을 것입니다.
실제로 모든 도메인이 동일하거나 도메인 전문가는 아닙니다. 어쨌든 일부 도메인에는 많은 영어 용어 (예 : 기술 중심 도메인)가 있으며 전체 영어 선택을 선택하는 것이 합리적입니다. 그러나 일부 문화권은이 선택에 영향을 줄 수 있으며 (프랑스어가 떠오름) 영어 용어의 확산은 국가마다 다릅니다. 일부 다른 도메인 (법률, 이름 지정)에서는 일부 용어를 번역 할 방법이 없습니다. 또는 번역하면 도메인 전문가가 대화를 따르는 것이 절대적으로 어려워집니다.
일반적으로 도메인 전문가의 의견에 더 관심이 있습니다. 그래서 우리는 그것들을 쉽게 만들려고합니다. 그렇지 않으면 UML 클래스를 가져 와서 다이어그램을 읽을 수 있습니다 (농담이었습니다). “도메인 전문가 행동에주의를 기울여야합니다.”대화에 참여하고 대화가 순조롭게 진행되는 경우에는 해당 언어를 그대로 유지 하는 것 입니다. 팀에 약간의 추가 작업이 발생할 수 있지만 괜찮습니다. 개발자로서 우리는 문맥에서 특정한 의미를 가진 단어를 배우도록 다소 훈련되었습니다.
이상하게도이 질문에는 항상 모든 코드가 한 언어를 사용해야한다는 가정이 수반됩니다. 그것도 도전받을 수 있습니다. 나는 모국어가 아니며 외국어에 대한 지식이 평평하지 않습니다. 이름 , 성 , 자동차 등에 대해 이야기 할 때 뇌가 빨리 가고 , 우편 번호 에 대해 이야기 할 때 세부 사항이 누락되고, 대출 에 대해 이야기 할 때 속도가 느려지고 확실히 묻습니다. 모기지 에 관해 이야기 할 때 안심할 수있는 설명을 위해 .
따라서 주요 대화 흐름을 만들고 도메인 전문가의 정보와 피드백을 최대한 제공 할 수있는 최상의 조합을 다시 선택하십시오.
답변
나는 보통 다른 언어로 번역 된 경우에도 특정 기술 단어를 언어 중립으로 간주합니다.
예를 들어, 독일어로 코딩하는 것에 대해 이야기 할 때, 독일어에 해당하는 단어가 있더라도 영어 단어는 마치 독일어 단어 인 것처럼 사용합니다.
귀하의 경우 나는 반대를 할 것입니다. 수세기 동안 외국어를 가져온 것처럼 특정 기술 단어를 모국어에서 영어로 가져옵니다. 영어 단어처럼 문법적으로 동작하게하십시오. 처음에는 이상하게 느껴지지만 익숙해집니다.
답변
나는 항상 다국어 개발 노력의 문제가되는 대부분의 프로그래밍 언어 ‘호흡’영어 의견에 동의합니다.
일반적으로 프로그래밍 팀 언어로 UL을 사용합니다.
우리가 과거에 한 일은 도메인 주제를 더 잘 표현할 수있는 새로운 단어를 만드는 것입니다. 프랑스어 / 영어 프로젝트에서는 주로 영어 기반이지만 프랑스어 풍미 (어쨌든 많은 영어 단어가 프랑스어 인 것처럼 어렵지 않음)로 구성된 단어를 구성하지만 이는 모든 언어 혼합에 적용될 수 있습니다.
예 :
“수량 부아”
영어에서는 “나무의 양”또는 “나무의 양”, 프랑스어의 경우 “quantité de bois”이므로 두 스피커 모두에 가깝습니다. 이것은 각 화자가 배울 새로운 단어의 양을 줄여야합니다
귀하의 도메인 UL은 얼마나 큽니까? 이것이 문제가됩니다. 핵심 문구가 100 개 미만인 경우 하이브리드 구성 스타일 언어를 사용할 수 있습니다. 더 크면 일반적으로 개발자가 더 강렬하게 처리해야하므로 개발자의 주된 언어를 고수합니다.
모든 사람이 필요에 따라 참조 할 수 있도록 Wiki 사전 / 동의어 사전 게시
답변
나는 최근 스위스의 DDD 프로젝트에서 일했으며, 도메인은 세금이었습니다 (특히 VAT 및 다른 종류의 세금 … 영어로 쉽게 번역 할 수는 없습니다 …).
그들은 첫 번째 옵션을 선택했습니다 : 독일어의 UL, 독일어의 코드에도 사용되었습니다.
이 프로젝트를 수행하기 전에 혼합 언어 코드에 대해 똑같은 혐오감을 가졌습니다. 나는 영어를 모국어로 사용하지는 않지만 영어로 모든 것을 갖고 싶어합니다. 나는 또한 독일어 원어민이 아닙니다. 그래서 코드베이스를 탐색하기 시작했을 때 나는 충격을 받았습니다.
이 프로젝트에서 일한 지 1 년이 지난 지금이 결정이 옳은 결정이라고 생각해야합니다 (우리는 프랑스어 또는 이탈리아어, 다른 공식 스위스 언어를 사용할 수도 있었지만 프로젝트의 대부분의 배우는 네이티브 독일어였습니다) 스피커).
도메인의 많은 특정 용어는 실제로 의미있는 방식으로 영어로 번역 할 수 없었습니다. 어쨌든 팀의 다른 팀과 의사 소통하기 위해 독일어 용어를 배워야했습니다. 어쨌든 얇은 공중에서 발명 된 영어 번역을 배워야한다는 것은 더 지저분 할 것입니다.
그래서 그것은 실제로 도메인에 달려 있다고 생각합니다. 일부 도메인은 영어로 번역하기가 매우 어려워서 의미가 없습니다.
아마도 모국어에도 의존 할 것입니다. 독일어는 거의 영어와 같은 방식으로, 특히 같은 순서로 단어를 작성할 수있는 언어입니다. 예를 들어 세금 신고 는 Steuerdeklaration 입니다. 놀랍게도 다르지 않습니다.
예를 들어, 프랑스어로 동등한 클래스 이름을 만드는 방법을 모르겠습니다. 예를 들어 중간 용어는 반대 순서와 여분의 전치사와 함께 자연어 용어 “déclaration d’ impôts”였습니다. 간단한 예입니다. 라틴어 (프랑스어, 스페인어, 이탈리아어, 포르투갈어 …)로 그러한 종류의 명명에 경험이있는 사람이 있다면 정말 흥미로울 것입니다!
또 다른 도전은 복수형으로, 독일어에서는 단수형과 거의 구별하기 어려운 경우가 있습니다 (영어로는 거의 항상 끝에 s 가 있습니다).
강조된 문자는 괜찮습니다. 독일어에서는 모두 강조되지 않은 문자 ( ü- > ue 등)가 있기 때문입니다. 프랑스가 더 문제가 될 수있는 또 다른 지점입니다 …