ทำไม Domain Models ถึงมีความสำคัญมากขึ้นในยุค AI

สถาปัตยกรรมซอฟต์แวร์มักจะเป็นการถกเถียงที่ไม่มีผู้ชนะ คุณสร้างระบบขึ้นมาหนึ่งระบบ แต่คุณไม่มีวันได้สร้างระบบทางเลือกภายใต้เงื่อนไขเดียวกัน สิ่งนี้ทำให้ทุกการตัดสินใจไม่สามารถพิสูจน์ความผิดพลาดได้ (unfalsifiable) เมื่อระบบล้มเหลว ผู้คนมักจะโทษโดเมนหรือโทษทีมงาน แต่พวกเขาแทบจะไม่โทษสถาปัตยกรรมเลย เพราะไม่มีกลุ่มควบคุม (control group) มาเปรียบเทียบ

เราต้องการวิธีในการทดสอบการออกแบบของเรา เราต้องแยก "ความซับซ้อนที่จำเป็น" (essential complexity) ออกจาก "ความซับซ้อนที่เกิดจากความไม่ตั้งใจ" (accidental complexity) ความซับซ้อนที่จำเป็นคือตัวปัญหาที่แท้จริง ส่วนความซับซ้อนที่เกิดจากความไม่ตั้งใจคือความยุ่งเหยิงที่เราสร้างขึ้นเองผ่านเครื่องมือและกระบวนการต่างๆ

AI ทำให้การเขียนโค้ด (implementation) แทบจะไม่มีต้นทุน นี่คือการเปลี่ยนแปลงครั้งใหญ่ ในอดีต ความยากลำบากในการเขียนโค้ดบีบบังคับให้เหล่านักพัฒนาต้องสร้างโครงสร้างที่ดีขึ้น หากโค้ดของคุณยุ่งเหยิง มันจะจัดการได้ยาก และความเจ็บปวดนั้นเองที่เป็นวงจรการตอบกลับ (feedback loop)

AI กำจัดความยากลำบากนั้นออกไป มันสามารถเขียนโค้ดที่ยุ่งเหยิงและมีโครงสร้างแย่ๆ ได้เร็วพอๆ กับโค้ดที่สะอาด (clean code) ความเจ็บปวดจากโมเดลที่ไม่ดีจะไม่ส่งผลกระทบต่อนักพัฒนาในระหว่างขั้นตอนการ build อีกต่อไป แต่ความเจ็บปวดนั้นจะย้ายไปอยู่ที่ production แทน คุณจะได้พบกับข้อมูลที่ผิดเพี้ยนและงานด้านการเชื่อมต่อระบบ (integration) ที่เป็นไปไม่ได้

Rich domain model คือเครื่องมือในการป้องกันสิ่งนี้ โดยทำหน้าที่สำคัญ 3 ประการ:

  • ช่วยให้คุณเรียนรู้โดเมนโดยการบังคับให้คุณต้องกำหนดรูปร่างให้กับแนวคิดต่างๆ
  • กำหนดขอบเขตของโดเมน เพื่อให้ "สิ่งที่ต้องสร้าง" ไม่ใช่การคาดเดาอีกต่อไป
  • บันทึกรายละเอียดของโดเมนไว้ในโค้ด ซึ่งจะได้รับการอัปเดตอยู่เสมอผ่านคอมไพเลอร์ (compiler)

เพื่อให้ได้ผลลัพธ์ที่ดี Domain model ต้องปฏิบัติตามกฎ 3 ข้อ:

  • รักษาความซับซ้อนที่จำเป็นไว้ให้เป็นหนึ่งเดียว อย่ากระจายแนวคิดเดียวออกไปใน microservices นับร้อยตัว
  • ให้การตอบกลับ (feedback) ข้อสันนิษฐานที่ผิดพลาดควรทำให้เกิด compile error ไม่ใช่เป็นบั๊กที่เงียบเชียบ (silent bug)
  • ทำให้การเปลี่ยนแปลงมีต้นทุนต่ำ คุณควรแก้ไขแนวคิดได้ในที่เดียว ไม่ใช่ต้องไล่หาตามบริการต่างๆ ถึงสิบแห่ง

หากคุณแยกโดเมนออกเป็น microservices เร็วเกินไปเพื่อแก้ปัญหา "ความเทอะทะ" (bloat) บ่อยครั้งคุณก็แค่ย้ายความยุ่งเหยิงไปที่อื่น คุณกำลังแลก "god object" เพียงหนึ่งเดียว กับความยุ่งเหยิงแบบกระจายตัวที่ติดตามได้ยากกว่าเดิม ความสัมพันธ์ที่เกี่ยวเนื่องกัน (dependency) ที่คุณมองไม่เห็น คือความสัมพันธ์ที่จะทำให้ระบบพังใน production

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

ที่มา: https://dev.to/leonpennings/what-is-the-reason-for-using-a-rich-domain-model-in-the-age-of-ai-3gg

ชุมชนแห่งการเรียนรู้ (ไม่บังคับ): https://t.me/GyaanSetuAi