나는 여기에 이미이 주제와 밀접한 관련이있는 몇 가지 질문이 있지만 Ubiquitous Language 를 시작점으로 사용하는 질문은 아무도 없으므로이 질문을 정당화한다고 생각합니다.
모르는 사람들을 위해 : 유비쿼터스 언어는 번역 문제와 오해로 인한 불일치와 잘못된 의사 소통을 피하기 위해 개발자와 도메인 전문가가 똑같이 사용하는 (말하고 쓰는) 언어를 정의하는 개념입니다. 코드, 팀원 간의 대화, 기능 사양 및 기타 사항에 동일한 용어가 표시됩니다.
그래서 제가 궁금한 것은 영어 이외의 도메인에서 유비쿼터스 언어를 다루는 방법입니다.
개인적으로, 나는 주석을 포함하여 물론 프로그래밍과 상수를 제외한 모든 프로그래밍 코드를 영어로 작성하는 것이 좋습니다.
그러나 영어 이외의 도메인에서는 다음 중 하나를 결정해야합니다.
- 도메인의 자연 언어로 유비쿼터스 언어를 반영하는 코드를 작성하십시오.
- 유비쿼터스 언어를 영어로 번역하고 도메인의 자연어 통신을 중단하십시오.
- 유비쿼터스 언어가 영어로 번역되는 방식을 정의하는 테이블을 정의하십시오.
다음은 이러한 옵션에 대한 내 생각 중 일부입니다.
1) 영어가 아닌 유형 / 멤버 / 변수 이름 등을 사용하여 코딩하는 혼합 언어 코드에 대한 강력한 혐오가 있습니다. 대부분의 프로그래밍 언어는 대부분 영어를 '호흡'하며 대부분의 기술 문헌, 디자인 패턴 이름 등은 영어로되어 있습니다. 따라서 대부분의 경우 영어 이외의 언어로 코드를 작성하는 방법이 없으므로 혼합 언어로 끝납니다.
2) 이것은 도메인 전문가들이 UL과 동등한 영어로 사고하고 말하기 시작하도록 강제 할 것입니다. 이는 아마도 그들에게 자연스럽게 오지 않을 것이므로 의사 소통을 크게 방해합니다.
3)이 경우 개발자는 모국어로 도메인 전문가와 의사 소통하는 반면 개발자는 영어로 서로 의사 소통하며 가장 중요하게는 UL의 영어 번역을 사용하여 코드를 작성합니다.
첫 번째 옵션으로 가고 싶지 않다고 확신하고 옵션 3이 옵션 2보다 훨씬 낫다고 생각합니다. 어떻게 생각하십니까? 다른 옵션이 없습니까?
최신 정보
약 1 년 후인 오늘,이 문제를 매일 다루면서 옵션 3이 제게 잘 작동했다고 말해야합니다.
내가 처음에 두려워하고 실시간으로 번역하는 것은 고객과 대화하는 것이 문제가 아니기 때문에 지루하지 않았습니다.
또한 내 경험을 바탕으로 다음과 같은 장점이 있음을 알았습니다.
- UL을 번역하면 특히 용어를 번역하는 방법을 모르고 사전 등을 살펴보아야 할 때 UL 및 도메인 자체를 정의하는 데 더 많은주의를 기울일 수 있습니다. 이로 인해 도메인 모델링 결정을 재고해야했습니다. 몇 번.
- 그것은 당신이 영어에 대한 지식을 더 깊이 이해할 수 있도록 도와줍니다.
- 분명히, 당신의 코드는 외설스러워하는 마음 대신에 보는 것이 훨씬 즐겁습니다.