การเขียนโปรแกรมและ Ubiquitous Language (DDD) ในโดเมนที่ไม่ใช่ภาษาอังกฤษ

ฉันรู้ว่ามีคำถามอยู่แล้วที่นี่ที่เกี่ยวข้องอย่างใกล้ชิดกับหัวข้อนี้ แต่ไม่มีคำถามใดที่ใช้ภาษา Ubiquitousเป็นจุดเริ่มต้นดังนั้นฉันคิดว่านั่นเป็นเหตุผลสำหรับคำถามนี้

สำหรับผู้ที่ไม่ทราบ: Ubiquitous Language เป็นแนวคิดของการกำหนดภาษา (ทั้งการพูดและการเขียน) ที่ใช้อย่างเท่าเทียมกันในการพัฒนาและผู้เชี่ยวชาญด้านโดเมนเพื่อหลีกเลี่ยงความไม่สอดคล้องกันและการสื่อสารผิดเนื่องจากปัญหาการแปลและความเข้าใจผิด คุณจะเห็นคำศัพท์ที่เหมือนกันปรากฏในรหัสการสนทนาระหว่างสมาชิกในทีมรายละเอียดการทำงานและ whatnot

ดังนั้นสิ่งที่ฉันสงสัยเกี่ยวกับวิธีจัดการกับภาษาแพร่หลายในโดเมนที่ไม่ใช่ภาษาอังกฤษ

ส่วนตัวผมชอบอย่างยิ่งที่จะเขียนโค้ดโปรแกรมเป็นภาษาอังกฤษอย่างสมบูรณ์รวมถึงความคิดเห็น แต่แน่นอนว่าไม่รวมค่าคงที่และทรัพยากร

อย่างไรก็ตามในโดเมนที่ไม่ใช่ภาษาอังกฤษฉันถูกบังคับให้ตัดสินใจ:

1. เขียนโค้ดที่สะท้อนถึงภาษา Ubiquitous ในภาษาธรรมชาติของโดเมน
2. แปลภาษา Ubiquitous เป็นภาษาอังกฤษและหยุดการสื่อสารในภาษาธรรมชาติของโดเมน
3. กำหนดตารางที่กำหนดวิธีการแปลภาษา Ubiquitous เป็นภาษาอังกฤษ

นี่คือความคิดของฉันตามตัวเลือกเหล่านี้:

1) ฉันมีความเกลียดชังอย่างมากต่อรหัสภาษาผสมนั่นคือการเข้ารหัสโดยใช้ประเภท / สมาชิก / ชื่อตัวแปร ฯลฯ ที่ไม่ใช่ภาษาอังกฤษ ภาษาโปรแกรมส่วนใหญ่ 'หายใจ' ภาษาอังกฤษในระดับใหญ่และส่วนใหญ่ของวรรณคดีทางเทคนิคชื่อรูปแบบการออกแบบและอื่น ๆ เป็นภาษาอังกฤษเช่นกัน ดังนั้นในกรณีส่วนใหญ่จะไม่มีวิธีการเขียนโค้ดทั้งหมดในภาษาที่ไม่ใช่ภาษาอังกฤษดังนั้นคุณจึงต้องลงเอยด้วยภาษาที่ผสมกันอยู่แล้ว

2) สิ่งนี้จะบังคับให้ผู้เชี่ยวชาญด้านโดเมนเริ่มคิดและพูดในภาษาอังกฤษเทียบเท่ากับ UL ซึ่งเป็นสิ่งที่อาจไม่เป็นธรรมชาติสำหรับพวกเขาดังนั้นจึงเป็นอุปสรรคต่อการสื่อสารอย่างมีนัยสำคัญ

3) ในกรณีนี้ผู้พัฒนาสื่อสารกับผู้เชี่ยวชาญโดเมนในภาษาของตนในขณะที่นักพัฒนาสื่อสารกันเป็นภาษาอังกฤษและที่สำคัญที่สุดพวกเขาเขียนโค้ดโดยใช้การแปลภาษาอังกฤษของ UL

ฉันแน่ใจว่าฉันไม่ต้องการไปที่ตัวเลือกแรกและฉันคิดว่าตัวเลือกที่ 3 นั้นดีกว่าตัวเลือกที่ 2 คุณคิดอย่างไร? ฉันไม่มีตัวเลือกอื่นหรือไม่

UPDATE

วันนี้ประมาณหนึ่งปีต่อมาการจัดการกับปัญหานี้เป็นประจำทุกวันฉันต้องบอกว่าตัวเลือกที่ 3 ใช้ได้ดีสำหรับฉัน

มันไม่น่าเบื่อเท่าที่ฉันเริ่มกลัวและแปลแบบเรียลไทม์ในขณะที่คุยกับลูกค้าก็ไม่เป็นปัญหาเช่นกัน

ฉันพบว่าข้อดีดังต่อไปนี้เป็นจริงตามประสบการณ์ของฉัน

• การแปล UL ทำให้คุณให้ความสำคัญกับการกำหนด UL และแม้กระทั่งโดเมนเองโดยเฉพาะอย่างยิ่งเมื่อคุณไม่ทราบวิธีการแปลคำศัพท์และคุณต้องเริ่มมองผ่านพจนานุกรม ฯลฯ สิ่งนี้ทำให้ฉันต้องพิจารณาการสร้างแบบจำลองโดเมนอีกครั้ง ไม่กี่ครั้ง.
• มันช่วยให้คุณทำให้ความรู้ภาษาอังกฤษของคุณลึกซึ้งยิ่งขึ้น
• เห็นได้ชัดว่ารหัสของคุณน่าดูมากกว่าที่จะเป็นความคิดที่หยาบคายอนาจาร

ฉันประสบปัญหานี้บ่อยครั้งและในความเห็นของฉันคำตอบคือ: "ไม่มีคำตอบเดียวที่ถูกต้องสำหรับทุกสถานการณ์"

แต่โปรดจำไว้ว่าภาษาที่ใช้กันแพร่หลายไม่ใช่เป้าหมายต่อหนึ่ง เป็นเครื่องมือในการเสริมสร้างการสื่อสารระหว่างทีมงานและผู้เชี่ยวชาญด้านโดเมนและเพื่อบังคับใช้การเชื่อมโยงแนวคิดของรูปแบบการใช้งานในรหัสการทดสอบและการสนทนา

หากคุณสามารถพูด UL ได้อย่างไม่น่าสงสัยคุณกำลังอยู่บนเส้นทางที่ถูกต้อง หากคุณและเพื่อนร่วมงานของคุณกำลังแปลจากรหัสเป็นบทสนทนาอย่างต่อเนื่องหรือจากแนวความคิดไปสู่แนวคิดคุณอาจไม่ได้รับการติดตาม

ในทางปฏิบัติโดเมนทั้งหมดไม่เท่ากันหรือผู้เชี่ยวชาญโดเมน บางโดเมนมีคำศัพท์ภาษาอังกฤษจำนวนมากอยู่แล้ว (เช่นโดเมนที่ใช้เทคโนโลยีเป็นหลัก) และมันฟังดูสมเหตุสมผลที่จะเลือกใช้ตัวเลือกภาษาอังกฤษแบบเต็ม อย่างไรก็ตามบางวัฒนธรรมอาจมีอิทธิพลต่อตัวเลือกนี้ (ภาษาฝรั่งเศสคำนึงถึง) และการกระจายคำศัพท์ภาษาอังกฤษแตกต่างกันไปในแต่ละประเทศ ในบางโดเมนอื่น ๆ (ตามกฎหมายเพื่อตั้งชื่อ) ไม่มีวิธีแปลคำศัพท์บางคำ หรือการแปลจะทำให้ Domain Expert ติดตามการสนทนาได้ยากขึ้น

โดยทั่วไปแล้วเรามีความสนใจในสิ่งที่ผู้เชี่ยวชาญด้านโดเมนพูด ดังนั้นเราจึงต้องการทำให้สิ่งต่าง ๆ เป็นเรื่องง่ายสำหรับพวกเขา มิฉะนั้นพวกเขาสามารถเรียน UML และอ่านแผนภาพของเรา (นั่นเป็นเรื่องตลก) ดังนั้นเพียงคำแนะนำของจริงที่นี่คือ "ใส่ใจกับพฤติกรรมผู้เชี่ยวชาญโดเมน" ถ้าพวกเขากำลังมีส่วนร่วมในการสนทนาและการสนทนาไปได้อย่างราบรื่น, คุณอาจในการติดตามให้ว่าภาษา มันอาจทำให้เกิดการทำงานเพิ่มเติมเล็กน้อยในทีม แต่ก็ไม่เป็นไร ในฐานะนักพัฒนาเราค่อนข้างได้รับการฝึกฝนให้เรียนรู้คำศัพท์ที่มีความหมายเฉพาะในบริบท

แปลกคำถามนี้มักจะมาพร้อมกับสมมติฐานที่ว่ารหัสทั้งหมดต้องพูดภาษาเดียว นั่นอาจเป็นสิ่งที่ท้าทายเช่นกัน ฉันไม่ได้เป็นภาษาอังกฤษและความรู้ภาษาต่างประเทศไม่แบน: สมองของฉันไปอย่างรวดเร็วเมื่อพูดถึงชื่อ , นามสกุล , รถและชอบคิดถึงรายละเอียดบางอย่างเมื่อพูดถึงรหัสไปรษณีย์ช้าลงเมื่อพูดคุยเกี่ยวกับการกู้ยืมเงินและแน่นอนถาม สำหรับคำอธิบายมั่นใจเมื่อพูดคุยเกี่ยวกับการจำนอง

ดังนั้นอีกครั้งให้เลือกชุดค่าผสมที่ดีที่สุดที่จะทำให้โฟลว์การสนทนาที่สำคัญและให้ข้อมูลจำนวนมากที่สุดและข้อเสนอแนะจากผู้เชี่ยวชาญด้านโดเมน

ฉันมักจะพิจารณาคำศัพท์ทางเทคนิคบางอย่างว่าเป็นภาษาที่เป็นกลางแม้ว่าจะมีการแปลเป็นภาษาอื่น

ตัวอย่างเช่นเมื่อพูดถึงการเข้ารหัสในภาษาเยอรมันฉันยังคงใช้คำศัพท์ทางเทคนิคภาษาอังกฤษราวกับว่าพวกเขาเป็นคำภาษาเยอรมันแม้ว่าจะมีความเทียบเท่าภาษาเยอรมัน

ในกรณีของคุณฉันจะทำตรงกันข้าม นำเข้าคำศัพท์ทางเทคนิคจากภาษาแม่ของคุณเป็นภาษาอังกฤษเช่นเดียวกับคำต่างประเทศที่นำเข้ามาหลายศตวรรษ ทำให้พวกเขามีพฤติกรรมทางไวยากรณ์เช่นคำภาษาอังกฤษ ตอนแรกมันรู้สึกแปลก ๆ แต่คุณจะชินกับมัน

ฉันเห็นด้วยกับความคิดเห็นภาษาอังกฤษ 'หายใจ' ภาษาโปรแกรมส่วนใหญ่ที่มักจะกลายเป็นปัญหากับความพยายามในการพัฒนาหลายภาษา

โดยปกติฉันจะมี UL ในภาษาของทีมการเขียนโปรแกรมของคุณ

สิ่งที่เราทำในอดีตคือการสร้างคำศัพท์ใหม่ที่แสดงหัวข้อโดเมนได้ดียิ่งขึ้น ด้วยโปรเจ็กต์ภาษาฝรั่งเศส / อังกฤษคำที่สร้างขึ้นซึ่งส่วนใหญ่อิงจากภาษาอังกฤษ แต่มีรสชาติแบบฝรั่งเศส (ไม่ยากเกินไปที่คำภาษาอังกฤษจะเป็นภาษาฝรั่งเศสอยู่ดี) แต่สิ่งนี้สามารถใช้ได้กับการผสมผสานภาษาใด ๆ

เช่น

"Bois ปริมาณ"

ในภาษาอังกฤษคือ "จำนวนไม้" หรือ "ปริมาณไม้" ในภาษาฝรั่งเศสคือ "quantité de bois" ดังนั้นจึงใกล้พอสำหรับลำโพงทั้งสอง สิ่งนี้ควรลดจำนวนคำศัพท์ใหม่ ๆ ที่ผู้พูดต้องเรียนรู้

โดเมนของคุณมีขนาดใหญ่แค่ไหน UL? นี่กลายเป็นปัญหา ถ้ามันน้อยกว่า 100 วลีที่สำคัญจากนั้นคุณสามารถใช้ภาษาสไตล์ไฮบริดที่ทำขึ้นถ้ามีขนาดใหญ่กว่าฉันจะติดภาษาที่โดดเด่นของนักพัฒนาที่พวกเขามักจะต้องจัดการกับมันอย่างเข้มข้นมากขึ้น

เผยแพร่พจนานุกรม / พจนานุกรมสำหรับวิกิพีเดียเพื่อให้ทุกคนสามารถอ้างอิงได้ตามที่ต้องการดังนั้นจึงไม่มีข้อแก้ตัวสำหรับความเข้าใจ

เมื่อเร็ว ๆ นี้ฉันทำงานโครงการ DDD ในสวิตเซอร์แลนด์โดเมนนั้นเป็นภาษี (โดยเฉพาะ VAT และภาษีประเภทอื่น ... ที่แปลไม่ได้เป็นภาษาอังกฤษได้อย่างง่ายดาย ... )

พวกเขาเลือกตัวเลือกแรก: UL ในภาษาเยอรมันใช้ในรหัสเป็นภาษาเยอรมันเช่นกัน

ก่อนที่ฉันจะทำงานในโครงการนี้ฉันมีความเกลียดชังเหมือนกับรหัสภาษาผสม ฉัน (ยัง) ชอบที่จะมีทุกอย่างในภาษาอังกฤษแม้ว่าฉันจะไม่ได้พูดภาษาอังกฤษ ฉันไม่ใช่คนพูดภาษาเยอรมัน ดังนั้นเมื่อฉันเริ่มสำรวจ codebase ฉันก็ตกใจ

หลังจากทำงานโครงการนี้มาหนึ่งปีฉันต้องยอมรับว่าฉันคิดว่ามันเป็นการตัดสินใจที่ถูกต้องในกรณีนี้ (เราอาจใช้ภาษาฝรั่งเศสหรืออิตาลีภาษาราชการอื่น ๆ ของสวิส แต่นักแสดงส่วนใหญ่ในโครงการเป็นภาษาเยอรมันพื้นเมือง ลำโพง)

คำศัพท์เฉพาะของโดเมนจำนวนมากไม่สามารถแปลเป็นภาษาอังกฤษได้อย่างมีความหมาย ฉันต้องเรียนรู้ศัพท์เยอรมันเพื่อสื่อสารกับคนอื่น ๆ ในทีม มันจะเป็นเรื่องยุ่งยากมากขึ้นที่จะต้องเรียนรู้การแปลภาษาอังกฤษด้วยซึ่งมันถูกประดิษฐ์ขึ้นมาจากอากาศที่บริสุทธิ์

ดังนั้นฉันคิดว่ามันขึ้นอยู่กับโดเมนจริงๆ บางโดเมนจะแปลยากเป็นภาษาอังกฤษจริง ๆ และจะไม่สมเหตุสมผล

มันอาจขึ้นอยู่กับภาษาพื้นเมืองด้วย ภาษาเยอรมันเป็นภาษาที่คุณสามารถเขียนคำในแบบเดียวกันโดยเฉพาะอย่างยิ่งในภาษาอังกฤษ ตัวอย่างเช่นการประกาศภาษีจะเป็นSteuerdeklaration ไม่แตกต่างกันอย่างน่าตกใจ

ฉันไม่รู้ว่าฉันจะสร้างชื่อคลาสที่เทียบเท่าในภาษาฝรั่งเศสได้หรือไม่คำว่าธรรมชาติคือ "déclarationd'impôts" โดยมีคำสั่งตรงกันข้ามและมีคำบุพบทพิเศษตรงกลาง ... และนั่นเป็นเพียง ตัวอย่างง่ายๆ ฉันจะสนใจถ้าใครมีประสบการณ์กับการตั้งชื่อในภาษาละติน (ฝรั่งเศส, สเปน, อิตาลี, โปรตุเกส ... )!

ความท้าทายอีกประการหนึ่งคือรูปพหูพจน์ซึ่งในเยอรมันเป็นบางครั้งแทบจะไม่แตกต่างจากเอกพจน์ (ในขณะที่ในภาษาอังกฤษมันมักจะมีsที่สิ้นสุด)

อักขระที่เน้นเสียงนั้นใช้ได้เนื่องจากในภาษาเยอรมันพวกเขาทุกคนมีความเท่าเทียมกันที่ไม่เน้น ( ü -> ueเป็นต้น) มันเป็นอีกจุดหนึ่งที่ชาวฝรั่งเศสจะมีปัญหามากกว่า ...