Ubiquitous Language

Ubiquitous Language คือภาษากลางที่ “เข้มงวด” ซึ่งทุกคนในทีมใช้ร่วมกัน อิงกับ Domain Model โดยตรง เหตุที่ต้องเข้มงวดเพราะ “ซอฟต์แวร์รับมือความกำกวมได้ไม่ดี” (Fowler)

ปัญหาคลาสสิกคือ ผู้เชี่ยวชาญธุรกิจพูดภาษาหนึ่ง นักพัฒนาพูดอีกภาษาหนึ่ง แล้วต้อง “แปล” ไปมา ทุกการแปลคือโอกาสที่ความเข้าใจจะคลาดเคลื่อน DDD แก้ด้วยการสร้างภาษาเดียวที่ใช้ทั้งในการคุยและใน code — ชื่อ class method ตัวแปร ควรสะท้อนคำในภาษานี้

คำเดียวกัน อาจหมายถึงคนละสิ่ง (polyseme)

Fowler ยกตัวอย่างบริษัทไฟฟ้าที่คำว่า “meter” (มิเตอร์) มีความหมายต่างกันเล็กน้อยในแต่ละแผนก ในการสนทนาเราอาจ “กลบ” ความต่างนี้ได้ แต่ในโลกที่แม่นยำของคอมพิวเตอร์ทำไม่ได้ ทางออกไม่ใช่บังคับให้ทุกคนใช้นิยามเดียว แต่คือการยอมรับว่าความหมายขึ้นกับ “บริบท” — ซึ่งนำเราไปสู่ Bounded Context ในบทถัดไป

ภาษา = model

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

เทียบกับ Cargo Shipping

🚢 หาคำที่ “คม”

ในระบบขนส่ง คำว่า “เส้นทาง” อาจหมายถึงสองสิ่งที่ต่างกันมาก: สิ่งที่ลูกค้าต้องการ (ต้นทาง–ปลายทาง–กำหนดเวลา) กับ แผนจริงที่จะเดินทาง (ผ่านท่าไหน เรือลำใด) ถ้าใช้คำเดียวปนกันจะสับสนทันที

DDD จึงตั้งชื่อแยกชัดเจน: Route Specification = ความต้องการของลูกค้า, Itinerary = แผนเดินทางจริง คำเหล่านี้กลายเป็นทั้งศัพท์ที่ทีมพูดและชื่อ class ใน code

// ภาษาใน code สะท้อนภาษาที่ทีมพูด
class RouteSpecification {
  constructor(
    readonly origin: UnLocode,       // ต้นทาง
    readonly destination: UnLocode,  // ปลายทาง
    readonly arrivalDeadline: Date,  // กำหนดถึง
  ) {}

  // “แผนนี้ตรงตามที่ลูกค้าต้องการไหม?” — อ่านได้เหมือนประโยคธุรกิจ
  isSatisfiedBy(itinerary: Itinerary): boolean {
    return itinerary.firstLeg().from.equals(this.origin)
        && itinerary.lastLeg().to.equals(this.destination)
        && itinerary.finalArrival() <= this.arrivalDeadline;
  }
}

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดในบทนี้ต่อได้ที่คลังอ้างอิง DevIQ:

Ubiquitous Language — นิยามและหลักการของภาษากลางที่บทนี้อธิบายโดยตรง
Bounded Context — บริบทที่ทำให้คำแบบ “meter” หรือ “เส้นทาง” มีความหมายต่างกันได้โดยไม่ขัดแย้งกัน
Domain Model — model ที่ Ubiquitous Language ต้องสะท้อนตรงกันทั้งในบทสนทนาและใน code
Specification — pattern เบื้องหลัง class RouteSpecification ในตัวอย่าง ที่ทำให้กติกาทางธุรกิจอ่านออกเป็นภาษาธุรกิจได้ตรงๆ

เช็กความเข้าใจ — Stage 1

ข้อ 1 / 3

ทำไม Ubiquitous Language จึงต้อง “เข้มงวด”?