สร้างโมเดลครั้งเดียว แสดงผลได้ทุกที่: UDA (Unified Data Architecture) ของ Netflix

 (netflixtechblog.com)
13 คะแนน โดย GN⁺ 2025-06-17 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Netflix กำลังเผชิญปัญหาด้านการทำงานร่วมกันและคุณภาพข้อมูล เนื่องจากการทำ data modeling ของโดเมนธุรกิจ (เช่น ภาพยนตร์ นักแสดง ซีรีส์ ฯลฯ) ซ้ำซ้อน ไม่สอดคล้องกัน และใช้คำศัพท์ที่ไม่เป็นมาตรฐานในแต่ละระบบ
  • UDA (Unified Data Architecture) มีเป้าหมายแบบ "สร้างโมเดลครั้งเดียว แสดงผลได้ทุกที่" โดยนิยามแนวคิดของโดเมนเพียงครั้งเดียว แล้วฉายและเชื่อมโยงไปยังหลายระบบอย่างสม่ำเสมอด้วยโครงสร้างพื้นฐานแบบ knowledge graph
  • UDA รองรับ การสร้างสคีมาอัตโนมัติ การแมป และการทำให้การเคลื่อนย้ายข้อมูลเป็นอัตโนมัติ จากโดเมนโมเดลไปยัง data container (เช่น GraphQL, Avro, Iceberg เป็นต้น)
  • ผู้ใช้ฝั่งธุรกิจสามารถใช้เครื่องมือที่อาศัย UDA เช่น Sphere และ PDM เพื่อสำรวจข้อมูล สร้างรายงาน และจัดการ reference data ได้เพียงค้นหาคำศัพท์
  • บนเทคโนโลยีเชิงความหมายอย่าง RDF และ SHACL มีการใช้ Upper metamodel ที่พัฒนาขึ้นเอง เพื่อให้ได้ทั้งการทำงานร่วมกันขนาดใหญ่ การกำกับดูแล ความสอดคล้องของสคีมา และความสามารถในการขยายระบบ

ความซับซ้อนที่เพิ่มขึ้นของระบบ Netflix และความท้าทายของโดเมนโมเดล

  • เมื่อบริการของ Netflix ขยายจากภาพยนตร์ ซีรีส์ เกม อีเวนต์สด ไปจนถึงโฆษณา ความซับซ้อนของระบบ ที่รองรับก็เพิ่มขึ้นอย่างมาก
  • แนวคิดธุรกิจหลัก อย่าง actor และ movie ถูกนิยามแยกกันในหลายระบบ เช่น Enterprise GraphQL Gateway, แพลตฟอร์มจัดการแอสเซ็ต, ระบบ media computing โดยทำงานกันแบบแยกส่วน ไม่มีการทำงานร่วมกันหรือแชร์ร่วมกัน
  • ส่งผลให้เกิดปัญหาดังต่อไปนี้
    • โมเดลซ้ำซ้อนและไม่สอดคล้องกัน: เอนทิตีเดียวกันถูกนิยามใหม่ในหลายระบบ ทำให้หลีกเลี่ยงความขัดแย้งได้ยาก
    • คำศัพท์ไม่สอดคล้องกัน: แม้แต่ภายในระบบเดียวกันก็อาจใช้คำต่างกัน หรือใช้คำเดียวกันซ้ำในคนละความหมาย ทำให้การสื่อสารสับสน
    • ปัญหาคุณภาพข้อมูล: มีความไม่สอดคล้องและข้อผิดพลาดของการอ้างอิงระหว่างไมโครเซอร์วิสจำนวนมาก อีกทั้งการจัดการ identifier และ external key ก็ยังไม่ดีพอจนต้องแก้ไขด้วยมือ
    • ข้อจำกัดด้านการเชื่อมโยง: ความสัมพันธ์ภายในระบบมีขอบเขตจำกัด และการเชื่อมต่อระหว่างระบบก็ไม่เพียงพอ
  • หากต้องการแก้ปัญหาเหล่านี้ จำเป็นต้องมีพื้นฐานที่ นิยาม conceptual model เพียงครั้งเดียวแล้วนำกลับมาใช้ซ้ำได้ทุกที่ พร้อมทั้งเชื่อมและบูรณาการเข้ากับระบบและข้อมูลจริงได้อย่างเป็นรูปธรรม

ภาพรวมของ UDA (Unified Data Architecture)

  • UDA คือ แพลตฟอร์มที่ขับเคลื่อนด้วยการเชื่อมโยงข้อมูล ภายใน Content Engineering ของ Netflix
  • นิยามโดเมนโมเดล (แนวคิดทางธุรกิจ) เพียงครั้งเดียว เพื่อฉายไปยังทุกระบบอย่างสอดคล้องกัน และรองรับระบบอัตโนมัติ การค้นพบ และ semantic interoperability
  • ความสามารถหลักที่ทำได้ด้วย UDA
    • การลงทะเบียนและเชื่อมโยงโดเมนโมเดล: ใช้นิยามแนวคิดอย่างเป็นทางการเป็นแหล่งข้อมูลเดียว เพื่อลดความสับสนระหว่างทีมและป้องกันการทำโมเดลซ้ำ
    • การแมประหว่างโดเมนโมเดลกับ data container: แสดงแนวคิดทางธุรกิจกับตำแหน่งและโครงสร้างที่เก็บข้อมูลจริง (เช่น ฐานข้อมูล ตาราง เซอร์วิส ฯลฯ) ในรูปแบบกราฟเพื่อให้เข้าใจได้ง่าย
    • การแปลงโดเมนโมเดลเป็นภาษาอธิบายสคีมา: แปลงอัตโนมัติไปยังระบบต่าง ๆ เช่น GraphQL, Avro, SQL, RDF, Java เพื่อลดงานทำมือและลดข้อผิดพลาด
    • การเคลื่อนย้ายข้อมูลที่เชื่อถือได้ระหว่าง data container: จัดการการแปลงและย้ายข้อมูลข้ามระบบ เช่น GraphQL entity, Data Mesh, CDC, Iceberg แบบอัตโนมัติ
    • การสำรวจและค้นหาแนวคิดของโดเมน: สามารถสำรวจและค้นหาความสัมพันธ์ระหว่างแนวคิดทางธุรกิจได้ ทำให้เข้าถึงข้อมูลที่ถูกต้องได้ง่าย
    • การทำ introspection แบบโปรแกรมได้ของ knowledge graph: ใช้ข้อมูลธุรกิจที่เชื่อมโยงผ่าน Java, GraphQL, SPARQL เพื่อทำระบบอัตโนมัติและดึงอินไซต์

สถาปัตยกรรมหลักของ UDA

  • อิงกับ Knowledge Graph

    • เป็น knowledge graph ที่สร้างบน RDF/SHACL โดยเชื่อมโยงทุกองค์ประกอบ เช่น โดเมนโมเดล สคีมา data container และ mapping เข้าด้วยกันในรูปข้อมูลแบบกราฟ
    • ใช้ information model ที่ยึด named graph เป็นแกนกลาง โดยแต่ละ named graph ปฏิบัติตามโมเดลการกำกับดูแลที่เป็นระเบียบ รองรับระบบการตีความ การทำโมดูล และนโยบายการปฏิบัติการ

  • Upper metamodel

    • Upper คือภาษาเมตาโมเดลที่ใช้กำหนดโดเมนโมเดลอย่างเข้มงวด
    • ใช้โมเดลแบบชนิดและลำดับชั้นเพื่ออธิบายเอนทิตีหลัก คุณสมบัติ และความสัมพันธ์ของแต่ละโดเมน และสามารถแทนด้วย RDF จัดการเวอร์ชัน และ query ได้
    • ตัว Upper เองก็ถูกสร้างโมเดลด้วย Upper เช่นกัน (self-reference, self-validation) เพื่อให้ทุกการขยายและการฉายมีความสอดคล้อง
    • ค่าของคุณสมบัติสามารถปรับให้เหมาะกับแต่ละโดเมนได้ และทุกแนวคิดถูกแทนด้วย conceptual RDF และ named graph รองรับ introspection การค้นหา และการจัดการเวอร์ชัน
    • Upper ใช้การยกระดับนามธรรมในระดับสูง พร้อมคัดเลือกเฉพาะส่วนสำคัญจากเทคโนโลยีเชิงความหมายของ W3C เช่น RDFS/OWL/SHACL ทำให้ทำโดเมนโมเดลได้อย่างมีประสิทธิภาพแม้ไม่ต้องเชี่ยวชาญแนวคิด ontology
    • จาก Upper metamodel สามารถ สร้าง Java API บน Jena และ GraphQL schema ได้อัตโนมัติ และเชื่อมต่อกับบริการ GraphQL จริง

  • Data container และ mapping

    • Data Container: แหล่งเก็บข้อมูลจริง เช่น entity ของบริการ GraphQL, Avro record ของแหล่งข้อมูล Data Mesh, แถวในตาราง Iceberg, object ใน Java API เป็นต้น
    • Mapping: นิยามการเชื่อมโยงแบบหนึ่งต่อหนึ่งระหว่างองค์ประกอบเฉพาะของโดเมนโมเดลกับ data container (เช่น ตาราง ฟิลด์ ฯลฯ)
    • ผ่าน mapping สามารถติดตามได้ว่าแนวคิดของโดเมนอยู่ที่ตำแหน่งข้อมูลจริงใด และในทางกลับกันก็สามารถสำรวจจากข้อมูลไปยังแนวคิดของโดเมนที่เกี่ยวข้องได้
    • การเคลื่อนย้ายข้อมูลและระบบอัตโนมัติตามเจตนา: ใช้ข้อมูล mapping ให้ระบบตัดสินใจเรื่องการไหลและการแปลงข้อมูลโดยอัตโนมัติ

  • Projections

    • แปลงและสร้างอัตโนมัติจากโดเมนโมเดลไปเป็นสคีมาของระบบเป้าหมาย (เช่น GraphQL, Avro ฯลฯ) รวมถึงการทำ automation ของโค้ด สคีมา และ pipeline
    • รับประกันความสอดคล้องของสคีมา และลดปัญหาการนิยามซ้ำและการซิงก์ให้เหลือน้อยที่สุด

กรณีใช้งานจริง

  • PDM (Primary Data Management)

    • แพลตฟอร์มจัดการ reference data และ taxonomy (ระบบจำแนกแบบลำดับชั้น)
    • แปลงโดเมนโมเดลเป็นการจัดหมวดหมู่แบบลำดับชั้นหรือแบบแบน และสร้าง UI สำหรับผู้ใช้ธุรกิจโดยอัตโนมัติ
    • ให้นิยามคำศัพท์ธุรกิจอย่างสม่ำเสมอ ใช้โมเดล SKOS และสร้าง Avro/GraphQL schema และ pipeline ด้วย UDA แบบอัตโนมัติ
    • เมื่อป้อนเพียงโดเมนโมเดล ระบบจะจัดเตรียม UI, data pipeline และ GraphQL API ให้อัตโนมัติ

  • Sphere (Operational Reporting)

    • เครื่องมือรายงานเชิงปฏิบัติการแบบ self-service ที่อิงกับ knowledge graph
    • ใช้การค้นหา สำรวจ และทำให้กลยุทธ์ join เป็นอัตโนมัติโดยอิงกับคำศัพท์ของโดเมน ทำให้ค้นพบข้อมูลและสร้างรายงานได้โดยไม่ต้องรับมือกับความซับซ้อนทางเทคนิค
    • ด้วย metadata และ mapping บน UDA ระบบสามารถระบุและดำเนินการทั้งตำแหน่งข้อมูลจริงและตรรกะการ join ได้โดยอัตโนมัติ
    • สามารถสำรวจแนวคิดด้วยคำที่คุ้นเคยอย่าง actor และ movie แล้วให้ระบบสร้าง SQL query อัตโนมัติตาม knowledge graph จากแนวคิดที่เลือก ทำให้ดึงข้อมูลได้โดยไม่ต้องเขียน join หรือทำงานเชิงเทคนิคเพิ่มเติม

บทสรุปและแนวโน้ม

  • UDA กำลังผลักดันการเปลี่ยนแปลงเชิงรากฐานในวิธีที่ Netflix ทำ data modeling และ data integration
  • ด้วยการนิยามโดเมนโมเดลเพียงครั้งเดียว ระบบทั่วทั้งองค์กรสามารถเชื่อมโยงข้อมูลได้อย่างสอดคล้อง เป็นอัตโนมัติ และขยายได้
  • ในอนาคตมีแผนรองรับเพิ่มเติม เช่น Protobuf/gRPC รวมถึงขยายขอบเขตการใช้งานไปสู่การทำให้ knowledge graph กลายเป็นข้อมูลจริง

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
trijin11 2025-06-19

ต้องจัดโครงสร้างอะไรคล้าย ๆ แบบนี้ แต่ตอนนี้ยังมืดแปดด้านเลยครับ
 
GN⁺ 2025-06-17
ความคิดเห็นจาก Hacker News

  • แม้จะมีข้อดีทั้งหมด แต่ก็คิดว่าวิธีนี้มีปัญหาใหญ่อย่างหนึ่งที่ไม่ค่อยถูกพูดถึง
    มันเป็นทั้งปัญหาธุรกิจและส่งผลต่อปัญหาทางเทคนิค จนสุดท้ายกลายเป็นปัญหาทางเทคนิครองที่กระทบความเร็วในการพัฒนา
    เมื่อธุรกิจผูกอยู่กับข้อตกลงที่ว่าทั้งองค์กรสามารถเชื่อถือคำนิยามข้อมูลแบบรวมศูนย์หนึ่งเดียวได้ เวลาจะนิยามหรือแก้ไขข้อมูลก็เลี่ยงไม่ได้ที่จะต้องคำนึงถึง use case หลากหลายของทั้งองค์กร ไม่ใช่แค่ของตัวเอง
    แม้แต่การเปลี่ยนแปลงเล็กน้อยก็ส่งผลต่อทั้งองค์กร จนเกิดกระบวนการที่ซับซ้อนถึงขั้นต้องผ่านการอนุมัติจากผู้มีส่วนได้ส่วนเสียจำนวนมาก
    นี่คือเวอร์ชันข้อมูลของปัญหาคลาสสิกในบริษัทใหญ่ที่ว่า “ทำไมแค่เปลี่ยนสีปุ่มถึงใช้เวลาสองเดือน”
    แน่นอนว่าปกติการทำสำเนาข้อมูลหรือปล่อยให้ข้อมูลกระจัดกระจายอย่างไม่สอดคล้องกันมักเป็นปัญหาที่ร้ายแรงกว่า
    แต่บางครั้งเวลาที่อยาก deploy การเปลี่ยนแปลงเล็ก ๆ แบบแยกขาดได้อย่างรวดเร็ว ระบบแบบนี้ก็กลายเป็นอุปสรรคใหญ่

    • เคยพัฒนาผลิตภัณฑ์เพื่อแก้ปัญหานี้มาก่อน
      เป็นแนวทางที่ให้ยึดโมเดลกลางขององค์กร แต่ก็สามารถทำ specialization ของโมเดลในระดับ local ได้ง่าย (โดยขยาย data definition language คล้าย Prolog และคิดเรื่องโมเดลองค์กรจากโลกความจริง ไม่ใช่จากสิ่งที่จำเป็นเฉพาะหน้า)
      น่าเสียดายที่ลองทำตอนกระแส NoSQL กับ Big Data กำลังมาแรงพอดี จังหวะเลยไม่ดี
      วัฒนธรรมของ NoSQL และ Big Data คือใช้โมเดลแบบหลวม ๆ ได้ และต่อให้ข้อมูลสูญหายหรือถูกตีความผิดไปบางส่วน ก็ค่อยมาปะทีหลังได้
      บรรยากาศตอนนั้นคือแทนที่จะออกแบบโมเดลให้แข็งแรงตั้งแต่ต้น ก็เชื่อว่าค่อยมาเก็บงานทีหลังง่ายกว่า ซึ่งก็เสียดายนิดหน่อยแต่ยอมรับได้

    • เห็นด้วยว่านี่เป็นปัญหาธุรกิจโดยเนื้อแท้ และเราคิดว่าสามารถแก้แบบเป็นระบบด้วยเทคโนโลยีได้
      เรามั่นใจว่าได้สร้างวิธีที่เป็นระบบมากขึ้นสำหรับการนำและ deploy model-first knowledge graph ภายใน enterprise
      UDA ระมัดระวังไม่ให้ทุกสิ่งที่มีคนขอเข้ามากลายเป็นงานเอกสารและขั้นตอนราชการเพิ่มขึ้น
      UDA อยู่ร่วมกับระบบเดิมได้ และไม่ได้บังคับให้ต้องรับไปใช้ทั้งหมด
      แต่ตั้งใจให้เป็นเครื่องมือที่ทรงพลังและใช้ง่ายสำหรับทีมที่อยากให้ business model ของตัวเองถูกใช้งานได้จากทุกที่ เชื่อมต่อ ขยาย และค้นพบได้ง่าย
      (ขอเปิดเผยว่าตัวเองเป็นหนึ่งในสถาปนิกของ UDA)

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

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

    • จากต้นฉบับไม่ได้อ่านออกมาว่าปฏิเสธว่าเป็นปัญหาธุรกิจ
      มุมมองคือโมเดลที่นิยามขึ้นมาถูกกำหนดข้ามทุกบทบาท และวิศวกรรมก็เป็นเพียงส่วนหนึ่งเท่านั้น

  • รู้สึกว่าก็ผ่านมานานมากแล้วตั้งแต่ยุคที่ Semantic Web, RDF, OWL, SKOS ปรากฏขึ้น
    ชอบที่ยังสนับสนุน W3C ต่อไป และไม่ได้สร้างล้อขึ้นใหม่ทั้งที่มีของอยู่แล้ว
    ไม่แน่ใจว่าวิธีแบบ UDA จะเป็นที่ยอมรับในวงกว้างไหม แต่ก็คาดหวังว่าเป็นความพยายามลดความยากอย่างก้าวกระโดดในการนำ DDD (การออกแบบที่ขับเคลื่อนด้วยโดเมน) และแนวคิดเชิง semantic ไปใช้ในองค์กรขนาดใหญ่
    ถ้าสามารถมอบชุดเครื่องมือและเทคโนโลยีร่วมที่แชร์ระบบความหมายของข้อมูลเดียวกันให้หลายทีมพัฒนาได้ และก่อให้เกิดผลแบบ “ดอกเบี้ยทบต้น (compound interest)” ก็อาจไม่ต้องฝืนทำให้ data contract แบนราบเพียงเพราะ DTO, POST และข้อจำกัดของการส่งผ่านเครือข่าย
    มอง Netflix ในแง่บวกที่ผลักดันและเปิดเผยการทดลองที่น่าสนใจแบบนี้

  • ทำให้นึกถึงโปรเจกต์ชื่อ Dragon ที่ Uber
    เคยทำงานที่เกี่ยวข้องกับ Dragon schema at Uber แต่สุดท้ายไม่ได้เปิดเป็นโอเพนซอร์ส
    หลังจากนั้น Joshua ย้ายไป LinkedIn และเข้าร่วมโปรเจกต์ LambdaGraph กับภาษา Hydra ซึ่งเปิดเป็นโอเพนซอร์สไว้ ที่นี่
    ข้อเสียของแนวทางแบบนี้หรือแม้แต่กระแส Semantic Web เมื่อ 10 ปีก่อน คือมีงานเพิ่มมหาศาลในการทำให้แนวคิดเป็นทางการและคอยดูแลรักษา
    ทุกวันนี้เลยสงสัยว่า LLM (โมเดลภาษาขนาดใหญ่) จะช่วยลดภาระนี้ได้ไหม

  • รู้สึกเสียดายนิดหน่อยกับการเลือกใช้คำว่า ‘domain model’ ในครั้งนี้
    เพราะ domain model ในที่นี้เป็นแนวคิดที่มีข้อมูลเป็นศูนย์กลางล้วน ๆ แต่การทำ domain modeling จริง ๆ แก่นสำคัญคือการโฟกัสที่ behavior มากกว่าโครงสร้างข้อมูล
    ข้อมูลใน domain model มีไว้เพื่อทำให้ behavior เกิดขึ้นได้ และตัว behavior เองต่างหากที่เป็นศูนย์กลางของโค้ด
    แม้ความซับซ้อนของการแสดง data modeling ให้หลากหลายตามมุมมองจะมีอยู่จริง แต่ก็คิดว่าความต่างนั้นอาจมองเป็นฟีเจอร์ได้
    ไม่ใช่ทุกสถานการณ์ที่ต้องการความซับซ้อนหรือความละเอียดเท่ากัน และโดยทั่วไป expression model ก็มักถูกปรับให้เหมาะกับ read scenario
    ถ้าใช้วิธีนี้ก็อาจเอนเอียงไปทางความเป็นหนึ่งเดียวมากกว่าการจัดการข้อมูลตามบริบท แม้ในสภาพแวดล้อมที่มีความเข้าใจโดเมนสูงอาจขยายได้ดีกว่า แต่จากประสบการณ์ ถ้าไม่ทำให้ domain model ที่ซับซ้อนหรือมีความละเอียดอ่อนง่ายลง use case ส่วนใหญ่ก็มักทำได้ยาก

  • มีคนถามว่า “เคยเห็นกรณีที่ความพยายามแบบนี้สร้างการปรับปรุงทางธุรกิจเชิงตัวเลขเกิน 5% หรือเกิน 5 ล้านดอลลาร์ไหม”
    เคยผ่านความพยายามรวม data table หลายครั้ง แต่ในทางปฏิบัติ ถ้าต้องการการวิเคราะห์ต่างกัน การรวม table ก็ไม่ได้มีความหมายมาก และการวิเคราะห์ที่หลากหลายก็ยังคงเกิดขึ้นแยกจากกันอยู่ดี
    กล่าวคือ ต่อให้รวม base layer ให้ตรงกับวิธีวิเคราะห์ที่ทุกคนต้องการ การวิเคราะห์ที่แตกต่างกันก็ยังดำเนินต่อไปแบบแยกส่วน
    ถึงอย่างนั้น ความพยายามครั้งนี้ก็ดูฉลาดตรงที่ไม่ได้พยายามบังคับรวมทุกอย่างเป็นหนึ่ง แต่พยายามเพิ่มความง่ายในการเข้าถึงอย่างกว้างขวาง
    เห็นด้วยอย่างมากกับเป้าหมายที่จะทำให้คำนิยามแนวคิดทางธุรกิจอย่างเป็นทางการเป็นแบบเดียวกันสำหรับทุกคน เพื่อลดความสับสน

    • เห็นด้วยมากกับประเด็นที่ว่า “แค่ทีมต่าง ๆ ทำการวิเคราะห์ต่างกันบนข้อมูลเดียวกัน ก็ไม่ได้แปลว่าสิ่งที่พวกเขากำลังจัดการต้องเป็นสิ่งเดียวกันเสมอไป”
      ตัวอย่างเช่น ต่อให้ทุกคนต้องการ master prison list เหมือนกัน แต่ prison นั้นจะหมายถึงตัวอาคารเอง กลุ่มผู้ต้องขัง (เช่น เรือนจำชาย/หญิงที่อยู่ในพื้นที่เดียวกันแต่ถือเป็นคนละหน่วย) หรือหน่วยงานที่ดำเนินงานภายใต้สัญญาเฉพาะ ก็แตกต่างกันโดยสิ้นเชิงตามนิยาม
      ในแง่นี้ แต่ละมุมมองในองค์กรย่อมต้องการ object ที่ต่างกันแบบละเอียดอ่อน

  • สงสัยว่ามันเกี่ยวข้องกับ DDD อย่างไร
    เพราะใน DDD ก็เหมือนจะตั้งอยู่บนสมมติฐานว่า แม้จะเป็นแนวคิดเดียวกันก็สามารถแสดงออกต่างกันไปในแต่ละระบบได้ไม่ใช่หรือ
    แต่ตัวบทความเองให้ความรู้สึกแบบ UML มากจนไม่ได้อ่านจนจบ

    • Domain ใน upper:DomainModel คือ Domain ตัวเดียวกับ D (โดเมน) ใน DDD และ DGS (Domain Graph Service) ก็เช่นกัน
      ใน DDD อนุญาตให้แนวคิดเดียวกันมีรูปแบบการแสดงออกต่างกันไปตามแต่ละระบบพร้อมกันได้ แต่ใน UDA ถูกออกแบบให้แนวคิดที่หลากหลายแบบนี้อยู่ร่วมกันอย่างชัดเจนภายในแต่ละโดเมน
      แนวคิดเรื่อง “เหมือนกัน” จึงกลายเป็นเรื่อง主観

    • กลับกัน รู้สึกโล่งใจที่ไม่ได้ใช้คำว่า "ubiquitous language (ภาษาร่วม)"
      เพราะแนวคิดนี้ตรงข้ามกับความพยายามครั้งนี้โดยสิ้นเชิง
      คนที่แค่เคยได้ยินคำที่เกี่ยวข้องแต่ไม่เคยลงลึก อาจไม่เห็นความแตกต่าง

  • สงสัยว่าทำไมทีมวิศวกรรมของ Netflix ถึงลงคอนเทนต์บน Medium
    ในเมื่อ Medium มีป๊อปอัปและสภาพแวดล้อมที่ทำให้เสียผู้อ่านได้ง่าย เลยสงสัยว่าคุ้มกับความเสี่ยงนั้นไหม

    • ทุกครั้งที่เห็น URL ของ Medium ที่เป็นเลขฐานสิบหก ก็ชอบอ่านผ่าน scribe.rip
      บทความ UDA บน scribe.rip

    • ถ้าทีมการตลาดเป็นคนดูแล เรื่องนี้ก็คงเป็นกลยุทธ์ที่รวม SEO อยู่ด้วย

    • ผลด้าน ‘การค้นพบ’ (discovery) ที่ Medium ให้มานั้นมีอยู่จริง
      และก็เป็นไปได้ว่าวิศวกรที่ชอบเขียนบทความบน Medium คือกลุ่มคนที่ Netflix อยากรับเข้าทำงาน

    • สะดวกกว่าเพราะไม่ต้องดูแลบล็อกเอง

  • สงสัยว่าเขาจัดการ versioning ของ data model หรือ breaking change อย่างไร
    ถ้าแยกโมเดลกันมากกว่านี้ก็ยังแก้เป็นชิ้น ๆ ตามวิธีเดิมได้ง่าย แต่ถ้าเป็นโมเดลรวมแบบนี้จะทำอย่างไร
    เดาว่าวิธีของ Netflix น่าจะเป็นการเพิ่มโมเดลใหม่ แล้วค่อย ๆ เลิกใช้โมเดลเก่าแบบเป็นขั้นเป็นตอน

    • การทำ versioning ก็เหมือนการให้สิทธิ์ในการ “ทำของเดิมพังได้”
      ใน UDA ยังไม่ได้ทำเสร็จสมบูรณ์ แต่มีแผนจะใช้แนวทางเดียวกับ Federated GraphQL
      ตั้งใจจะนำโมเดลการจัดการ deprecation ที่พิสูจน์แล้วใน Federated GraphQL มาใช้ และมีประสบการณ์จัดการ federated GraphQL schema มากกว่า 500 ตัวได้สำเร็จ
      แก่นสำคัญคือโรดแมปในการติดตาม consumer ของ projected models และบริหารรอบ deprecation เชิงรุก

  • รู้สึกว่าการจะทำ integrated graph ให้สำเร็จต้องแก้ทั้งสามด้านคือ ธุรกิจ การสื่อสาร และเทคนิค
    ปัญหาด้านการสื่อสารคือจำเป็นต้องทำลาย “ความเป็นอิสระแบบแฝง ๆ ของทีมที่ปกครองตัวเอง”
    ต้องมีคนทำหน้าที่เป็นสะพานข้ามทีมต่าง ๆ และช่วยวิเคราะห์ data model ด้วย
    แค่แชร์ schema อย่างเดียวไม่พอ ต้องมีขั้นตอนพูดคุยสัมภาษณ์และตกลงกับผู้คนโดยตรงด้วย
    ฝั่งเทคนิคกลับเป็นส่วนที่ง่ายที่สุด และถ้าบังคับใช้ “schema หนา” แบบ Microsoft Graph ก็ทำได้ไม่ยาก
    กระบวนการนี้ต้องใช้ความเข้าอกเข้าใจและความอดทนอย่างมาก
    การแก้ปัญหาทางเทคนิคจำเป็นต้องมีการตัดสินใจที่หนักแน่นจากผู้บริหารและอำนาจในการผลักดัน ถ้ายังปล่อยให้แต่ละทีมเคลื่อนไหวอย่างอิสระ ไอเดียไหนก็ใช้ไม่ได้ผล
    ด้านธุรกิจคือระดับความยากสูงสุด
    การเปลี่ยนกระบวนการและคำศัพท์ที่ถูกปรับแต่งมานาน 20 ปีในคราวเดียวนั้นแทบเป็นไปไม่ได้
    สุดท้ายแล้ว งานขนาดมหึมานี้จะคุ้มค่าที่จะลงทุน “ตลอดชีวิต” ก็ต่อเมื่อเกิด buy-in ทั้งองค์กรอย่างสมบูรณ์เท่านั้น

  • เชื่อว่าการนำคำศัพท์ร่วมมาใช้มีความหมายมาก
    แต่ยิ่งองค์กรขยายไปทั้งระดับบริษัท การควบรวมกิจการ กระบวนการธุรกิจที่หลากหลาย และมิติเวลา ก็ยิ่งยากขึ้นเรื่อย ๆ
    การทำอินเทอร์เฟซเพื่อเชื่อมต่อแค่สองระบบอาจทำได้เร็ว แต่เมื่อใน enterprise หนึ่งมีหลายเลเยอร์ และมีอุดมคติว่าจะใส่ความรู้ทั้งหมดลงในแคตตาล็อกหรือ DB เดียว ก็อดสงสัยไม่ได้ว่าใครจะเป็นคนสร้างและดูแลมันต่อเนื่องได้จริง
    ความพยายามที่อยู่รอดได้สำเร็จส่วนใหญ่ มักดำเนินการในระดับนามธรรมมาก ๆ หรือจำกัดขอบเขตไว้แค่ use case เฉพาะ

    • จากประสบการณ์ แม้จะนิยาม enterprise entity กลาง (เช่น นิติบุคคลทางการของบริษัท) ขึ้นมาแล้ว แต่แต่ละแผนกก็มักต้องการขยายมันต่อ และก็จะมีการตัดสินใจเชิงการเมืองหรือเชิงมองโลกในแง่ดีตามมาว่า attribute ใหม่ควรเปิดให้ทุกแผนกใช้ได้ หรือให้ใช้เฉพาะแผนกนั้น
      เมื่ออัปเดต entity กลาง ก็ต้องประเมินผลกระทบทั้งระบบและทำ change management อย่างเข้มงวด
      ถ้าสร้างได้ถูกต้องและมีวัฒนธรรมองค์กรที่เข้มแข็งรองรับ ต้นทุนและแรงเสียดทานจะลดลงได้มาก และถ้าเป็น Netflix ก็ดูมีโอกาสทำได้

    • มีการยก Wikidata เป็นตัวอย่างคำศัพท์ร่วมขนาดใหญ่ที่แทบจะเป็นหนึ่งเดียวและยังอยู่รอด
      ตอนนี้มี graph node ถึง 1.65 พันล้านรายการที่ยังคงขยายต่อไปภายใต้คำศัพท์มาตรฐานเดียวกัน