Domain Model สมดุลระหว่างเทคนิคและความเข้าใจที่แท้จริงในเชิง business
By @NexaByte Dispatches, ที่มา: Domain-Driven Design, Eric Evans
ในศตวรรษที่ 18 มีแผนที่จีนที่แสดงถึงโลกทั้งหมด ตรงส่วนกลางและพื้นที่ส่วนใหญ่เป็นของจีน โดยมีประเทศอื่นๆ ล้อมรอบ อย่างคร่าว ๆ แผนที่นี้เป็นตัวแทนของการมองโลกจากภายใน แต่เมื่อพิจารณามุมมองที่แผนที่นี้แสดง อาจพบว่าไม่สามารถช่วยในการสื่อสารหรือรับรู้กับชาวต่างชาติได้ดี แน่นอนว่าในยุคปัจจุบัน แผนที่แบบนี้อาจไม่เหมาะกับประเทศจีนแล้ว
แผนที่เป็นแบบแผนและทุกแบบแผนเป็นการแสดงบางมุมมองหรือความคิดที่น่าสนใจ แบบแผนเป็นการลดความละเอียด โดยเน้นเฉพาะส่วนที่เกี่ยวข้องกับการแก้ปัญหาที่มีอยู่และเลี่ยงรายละเอียดที่ไม่จำเป็นออกไป
เราสามารถเรียนรู้จากแผนที่แบบนี้ได้ว่า การมองโลกมีความสำคัญในการสร้างความเข้าใจและความสัมพันธ์กับผู้อื่น และการมีมุมมองที่เปิดกว้างอยู่เสมอจะช่วยให้เราสามารถรับรู้และปรับตัวกับความเปลี่ยนแปลงในโลกได้ดียิ่งขึ้น
ทุกๆ software application ถูกออกแบบมาเพื่อตอบสนองความต้องการหรือฟังก์ชันเฉพาะของผู้ใช้ ส่วนที่ program นี้ถูกนำไปใช้งาน เรียกว่า “Domain” ของ software มี domain หลายแบบที่เกี่ยวข้องกับสถานการณ์จริง ยกตัวอย่างเช่น Travel reservation system จัดการกับนักท่องเที่ยวจริงและยานพาหนะจริง ในขณะที่ domain บางส่วนเป็นแนวคิด ยกตัวอย่างเช่น Financial software’s domain มุ่งเน้นไปที่การทำธุรกรรมทางการเงินและการจัดการทางการเงิน แม้ว่าวัตถุประสงค์ของ software’s domain ส่วนใหญ่จะไม่ได้เกี่ยวกับ computer โดยตรง แต่ยังมีข้อยกเว้น เช่น software ที่จัดการ version control
การพัฒนา software ให้ตรงกับการใช้งานของผู้ใช้ ทีมพัฒนาต้องนำความรู้ที่เกี่ยวข้องกับงานเหล่านั้นออกมาใช้ เนื่องจากเราต้องการใช้ความรู้ที่มากขึ้น ปริมาณข้อมูลที่เยอะมากขึ้น รวมถึงความซับซ้อนของข้อมูลด้วย เมื่อพูดแบบนี้เลยทำให้เรารู้สึกว่ายากที่จะจัดการ นี่คือจุดที่คำว่า “Model” เข้ามามีบทบาท model ทำหน้าที่เป็นแนวทางให้กับการจัดการข้อมูลเหล่านี้ โดยออกแบบมาเพื่อแสดงให้เห็นถึงความรู้ที่ถูกคัดกรองและจัดระเบียบอย่างรอบคอบให้มันถูกต้อง อีกทั้ง Model ไม่เพียงแต่ทำให้ข้อมูลชัดเจนขึ้นแต่ยังทำให้สามารถใช้ข้อมูลนั้นแก้ปัญหาที่ต้องการได้อย่างมีประสิทธิภาพ
Domain model ไม่ใช่แค่การแค่แสดงผลลัพธ์ออกมาทางภาพเท่านั้น แต่เป็นแนวคิดหลักในการถ่ายทอดมันไม่ใช่เพียงแค่ความรู้แบบดิบ ๆ ที่มีอยู่ในหัวของผู้เชี่ยวชาญ แต่เป็นการสรุปและจัดระเบียบความรู้นั้นในรูปแบบที่เน้นเจาะจงเฉพาะจุดเพื่อแก้ไขปัญหา
[สมชาย]: เฮ้, นายเคยคิดเรื่องการสร้าง domain model ไหม? หรือคิดว่ามันเกี่ยวกับการสร้าง model ให้เหมือนของจริงมากที่สุดหรือเปล่า?
[สมใจ]: น่าสนใจนะ ฉันเคยคิดว่ามันต้องเกี่ยวกับชีวิตจริงนะ แต่จริง ๆ แล้วมันเป็นเรื่องของประโยชน์มากกว่าความจริง ลองคิดดูว่ามันเหมือนกับการสร้างหนัง
[สมชาย]: โอ้ หมายถึงการสร้างฉากในหนังให้เหมือนกับสถานการณ์จริงใช่ไหม?
[สมใจ]: ไม่โดยตรง แม้หนังสารคดีก็ไม่ได้แสดงชีวิตจริงๆ โดยไม่ต้องแก้ไข มันเป็นเรื่องของการเลือกบางส่วนของสถานการณ์หรือประสบการณ์ แล้วแสดงพวกมันออกมาผ่านการเล่าเรื่องเกี่ยวกับหัวใจหลักของเรื่อง
[สมชาย]: ก็เหมือนกับผู้กำกับที่เลือกฉากบางฉากเพื่อสื่อความหมาย ผู้สร้าง domain model เลือกเนื้อหาบางส่วนที่มีประโยชน์ที่สุดสำหรับ softwareใช่ไหม?
[สมใจ]: แน่นอน! มันไม่ใช่เรื่องของการทำให้สมบูรณ์แบบ แต่เป็นการทำให้ได้ประโยชน์มากที่สุด
[สมชาย]: อ๋อ! ก็เหมือนเราเลือกฉากที่ดีที่สุดสำหรับหนัง software ของเราเนี่ยแหละ!
เมื่อพูดถึงการพัฒนา software การสร้าง domain model เป็นหัวใจของกระบวนการทั้งหมด เพื่อให้ระบบที่พัฒนาขึ้นมาสามารถตอบสนองต่อความต้องการของผู้ใช้และสะท้อนถึงความซับซ้อนของชีวิตจริง Model และ Design เป็นส่วนที่ไม่สามารถแยกห่างออกจากกันได้ มันมีการสร้างความเชื่อมโยงทั้งจากภายในและภายนอกต่อกัน
การสร้าง domain model ที่มีประสิทธิภาพไม่ได้แปลว่าต้องสะท้อนความจริงในทุกๆ ด้าน แต่ต้องเป็นเครื่องมือที่ช่วยในการแปลความซับซ้อนของ domain เป็นภาษาของ code ที่สามารถทำงานและรับรองว่ามันจะให้ผลลัพธ์ที่ต้องการได้
ดังนั้นการเข้าใจ domain model และการสร้างความเชื่อมโยงระหว่าง model กับการ implementation เป็นสิ่งที่ขาดไม่ได้เช่นเดียวกัน Model ช่วยเป็นแนวทางในการเขียน code และแก้ไข อีกทั้งช่วยในการตัดสินใจด้านการ design การมี model ที่ดีจึงเป็นสิ่งสำคัญที่จะทำให้กระบวนการพัฒนา software มีประสิทธิภาพและรับผิดชอบต่อความต้องการของผู้ใช้ได้อย่างแท้จริง
[สมใจ]: นี่สมชาย, แกรู้มั้ยว่าเราคุยกันเกี่ยวกับความสำคัญของการมีภาษาที่ใช้ร่วมกันเพื่อให้ทุกคนในทีมเข้าใจกันบ่อยๆ?
[สมชาย]: อ๋อ แกหมายถึงการมี model ที่ทำให้เราทุกคนเข้าใจและใช้งานร่วมกันรึ?
[สมใจ]: ถูกแล้ว! model นั่นเหมือนกับโครงสร้างหลักของการสื่อสารของเราเลยล่ะ เพราะ code ของเราเกี่ยวข้องกับ model โดยตรง เราสามารถพูดคุยเกี่ยวกับ program ด้วยภาษาที่ทุกคนเข้าใจได้
[สมชาย]: โอ้ ฉันเข้าใจแล้ว ดังนั้นเวลาเราสื่อสารกับผู้เชี่ยวชาญในด้านนั้น เราก็ไม่ต้องมีใครแปลให้ ทุกคนพูดภาษาเดียวกัน
[สมใจ]: ถูกต้องเลย! และสิ่งที่เจ๋งคือหากภาษาของเรามีที่มาจาก model นี้ เราก็สามารถใช้ความสามารถในการพูดคุยด้วยภาษาของเราในการปรับปรุงและเพิ่มประสิทธิภาพของตัว model เหมือนการคุยปกติของเรากลายเป็นเครื่องมือในการ design ที่ดีขึ้น
[สมชาย]: นี่มันเจ๋งจริงๆ เหมือนเราเอาการคุยกันตอนพักกาแฟมาเปลี่ยนเป็นการสร้างไอเดียใหม่ๆ!
Model ที่ถูกสรุปออกมาแล้วมันไม่ใช่เป็นเพียงแค่โครงสร้างธรรมดา มันคือการแสดงถึงความเห็นชอบของทีมเกี่ยวกับวิธีการจัดการและเน้นย้ำส่วนที่สำคัญที่สุดของ domain โดยการเลือกคำที่เจาะจง, การวิเคราะห์, การแสดงถึงความคิด, และการเข้าใจความเชื่อมโยงของพวกมัน เหมือนเราได้สร้างแว่นที่ทำให้เราใช้มองเห็น domain ทำความเข้าใจร่วมกันหรือพูดคุยภาษาร่วมกัน ทำให้สามารถเชื่อมต่อระหว่าง developers และผู้เชี่ยวชาญในด้านนั้นได้โดยไม่มีอุปสรรค แถมเมื่อ model นี้เชื่อมต่อกันกับการ implementation ของ software การตอบรับจากเวอร์ชันแรกๆ ของ software สามารถเป็นปัจจัยที่ทำให้ model นั้นถูกปรับปรุงแก้ไขเพิ่มเติมได้
[สมชาย]: นี่ แก! ฉันกำลังคิดเกี่ยวกับจุดสำคัญของ software คือความสามารถในการแก้ไขปัญหาให้กับผู้ใช้งานจริงๆ ส่วนอื่นๆ เช่นฟีเจอร์ต่างๆ ทั้งหมดนั้นแค่ support เป้าหมายหลักแค่นั้นเอง
[สมใจ]: แน่นอน!โดยเฉพาะเมื่อปัญหาหรืออะไรที่ทำให้มันซับซ้อน เราควรต้องขุดซากและเข้าใจในตัว businessให้ลึกซึ้ง
[สมชาย]: ถูกเลย แต่มันแปลกไหมว่านักพัฒนาที่มีความสามารถหลายคนไม่ค่อยให้ความสำคัญกับสิ่งนี้? ฉันสังเกตุเห็นว่าหลายคนไม่ต้องการที่จะทำความเข้าใจในสิ่งพวกเขากำลังทำอยู่
[สมใจ]: ฉันเห็นด้วย 100% คนเทคนิคหลายคนเพียงแค่ชอบปัญหาที่ชัดเจน และเป็นปัญหาพวกเขาสามารถใช้ทักษะการเขียน code ของพวกเขาแก้ไขมันได้ การทำความเข้าใจในด้าน business มันเหมือนกับการเรียนรู้ภาษาใหม่ ซึ่งดูเหมือนจะไม่เพิ่มความสามารถให้พวกเขาเลยนะ
[สมชาย]: แน่นอน! แล้วพวกเขาก็เอาความสามารถทั้งหมดนั้นไปสร้าง framework โชว์เทคนิคที่ซับซ้อน พยายามแก้ปัญหา business ด้วยเทคโนโลยี ฮ่าๆ
[สมใจ]: ใช่ แล้วทำให้การทำความเข้าใจและการสร้าง model ของ business ถูกมอบหมายให้คนอื่น อีกอย่างถ้าเราไม่เผชิญหน้ากับความซับซ้อนที่เป็นใจกลางของ software เราก็จะเสี่ยงที่จะพบว่าสิ่งที่เราทำอยู่กลายเป็นซ่อมรอยผุของ software ไปเรื่อยๆ จนถึงจุดที่ไม่สามารถแก้ไขได้แล้ว
[สมชาย]: ทุกคำที่นายพูดมา ถูกต้องทุกประการ พวกเราต้องหาสมดุลระหว่างทักษะทางเทคนิคและความเข้าใจที่แท้จริงในเชิง business ให้ได้ก่อนลงมือเขียน code
ทิ้งท้าย “ถ้าผู้นำภายในทีมมีเข้าใจและมองเห็นความสำคัญของ domain แล้ว เมื่อไหร่ที่ในทีมเกิดความสับสนในระหว่างกระบวนการที่เกิดขึ้นได้ ผู้นำจะสามารถทำให้ software project ของพวกเขากลับเข้ามายังเส้นทางที่ถูกต้องได้อีกครั้ง”
