Domain Driven Design (DDD) ฉบับเข้าใจง่าย ๆ
ขออธิบายก่อนว่า Domain นี่ไม่ได้หมายถึง Domain Name แต่หมายถึง Business Domain คือการจัดการ โครงสร้างจุดประสงค์ของธุรกิจที่มีพฤติกรรม กระบวนการคิดและการแก้ไขปัญหาในแต่ละส่วนที่แตกต่างกัน ให้สอดคล้องกับการออกแบบโปรแกรม
สำหรับเพื่อน ๆ คนไหนยังไม่รู้ว่า Business Domain และ Sub Domain คือ ?
Domain Driven Design คือ ?
การออกแบบแนวทางที่จำลองความต้องการของธุรกิจให้สอดคล้องกับความเป็นจริง โดยความรู้จากผู้เชียวชาญหลากหลายแขนง ในการออกแบบซอฟต์แวร์ และโครงสร้างของข้อมูลรวมถึงวิธีการจัดการ
อธิบายง่าย ๆ คือ ไม่ใช่คนเดียวที่ออกแบบ Requirement แต่จะต้องทุกคนที่ได้มีส่วนเกี่ยวข้องกับธุรกิจในการออกแบบ Requirement ด้วย โดยแยกส่วนประกอบของธุรกิจให้ทำเฉพาะด้านที่สุด
ยกตัวอย่าง แต่เดิมธุรกิจขายของออนไลน์ คนที่ได้รับ Requirement ก็จะต้องคิดถึงการจัดการและการเก็บข้อมูลด้วยทุกครั้ง หากธุรกิจนั้นเติบโตขึ้น แม้เราจะทำการ normalization แล้วก็ตามปัญหาที่ตามมาคือ Databased ใหญ่ขึ้นด้วยปัจจัยธุรกิจที่เติบโต จำนวนคนที่มากขึ้น การจัดการที่ซับซ้อนขึ้นเพราะทุกอย่างกระจุกรวมกัน การบริหารจัดการก็ยากขึ้น
คำถามแล้วหากเราใช้ Databased แขนงอื่น ละเช่น Nosql ฯ ล ฯ
คำตอบ : เราก็ยังจะต้องพบเจอปัญหาเช่นเดิม ตราบใดที่เรายังให้ ธุรกิจขายของออนไลน์อยู่ใน Databased ตัวเดียวกัน (แล้วเราจะทำอย่างไร ท้อจังแหะ)
เสริมสร้างภูมิ
ขออธิบายก่อนไม่มีอะไรที่จีรัง ทุกอย่างย่อมมีจุดสิ้นสุด เช่นกันของออกแบบระบบ หากย้อนกลับไปเรามักจะเข้าใจว่า หากสิ่งใดที่จัดการในระดับ ซอฟต์แวร์ไม่ได้แล้วเราก็ควรจะจัดการในระดับฮาร์ดแวร์ต่อ สุดท้ายแล้วบางปัญหาก็จะไม่สามารถจัดการได้เพราะจะพบว่า การออกแบบที่เราพยายามสร้างมันมานั้น ล้วนแต่เป็นการฝืนธรรมชาติของมัน
ยกตัวอย่างที่ว่า ระบบขายของออนไลน์ มีการเก็บข้อมูล 2,000 Table มีข้อมูลหลากหลาย คอลัมน์และโรล รวมกันแล้ว 6000 ล้านแถว รวมถึงฟังก์ชั่นสำคัญมากมายเช่น ระบบซื้อขาย, ระบบรีวิว, ระบบสต็อกสินค้า
สมุตติพนักงานคนเก่าออก พนักงานคนใหม่เข้ามาโดยมีเติบโตของธุรกิจเพิ่มขึ้นอีก ฟังก์ชั่น ไลพ์สด, ระบบคะแนน, ระบบแชท, ระบบกู้ยืม พนักงานคนใหม่เข้าไปพบว่า ฉันมาทำอะไรที่นี่ 😢 โดยพัฒนาน้องใหม่ ก็จะต้องเรียนรู้การ พัฒนาที่ช้าลงเพราะต้องศึกษาข้อมูลทั้งโครงสร้าง รวมถึงผลข้างเคียงของการออกแบบที่เพิ่มเติมเข้าไป
ผู้เชียวชาญ บอกว่าปัญหาเหล่านี้แก้ไม่ยาก
หากเป็นที่ปัญหาไหนเราก็ควรจะจัดการปัญหาเหล่านั้น เป็นที่ Databased ใช่ไหมละ
- ได้ลองทำ Store procedure หรือยัง ?
- ได้ลองทำ View หรือยัง ?
- ได้ลองทำ Replication Table หรือยัง ?
- ได้ลองทำ Trigger หรือยัง ?
- ได้ลองทำ Normalization หรือยัง ?
สุดท้ายเราจะค้นพบว่าเมื่อ ธุรกิจขายของออนไลน์เติบโตขึ้น สิ่งที่เรียกว่า Databased ซับซ้อนเพิ่มขึ้นเป็นเงา และการจัดการ Overuse Databased จะคุ้มค่าไหม DDD เลยพยายามบอกเราว่า การเอาตรรกะทางธุรกิจ อยู่ใน Databased ทั้งหมดรวมศูนย์ นี่ละปัญหา
ฉะนั้นแล้ว เราต้องมาปรับความคิดก่อนว่าสิ่งนี่เป็นทางเลือกที่เรายอมรับได้หรือไม่ หากเรายอมรับว่ามันเป็นปัญหาและเราจะต้องจัดการ (แปลว่าเรายอมที่จะเปลี่ยนแปลงแล้ว)
กรณีที่เรามองว่าปกติ ไม่มีอะไรจะต้องเปลี่ยนแปลง (เราอาจจะนำแนวคิดและกระบวนการบางอย่างมาใช้บ้าง)
ยอมรับที่เปลี่ยนแปลง
เราถึงจะต้องนำแนวคิดของ DDD มาเพื่อเปลี่ยนแปลงกระบวนการคิดและวิธีการจัดการ ดังนั้นเราควรแยกรูปแบบธุรกิจในแต่ละส่วนที่มีความสำคัญของ ตรรกะทางธุรกิจ ออกมาเป็นส่วนประกอบย่อย ให้ชัดเจน ใครทำอะไร อย่างไร ที่ไหน เมื่อไหร่ และรูปแบบการทำเหมือนหรือใกล้เคียงกันในแต่ละกิจกรรมของธุรกิจหรือไม่
มันมีราคาจ่าย
ทุกสิ่งย่อมมีราคาจ่ายเสมอ ไม่ว่าเราจะกระทำอะไรก็ตาม ทุกวิธีทางเลือกมักจะมีผลตามมาเหมือนเงา ดังนั้นให้เราคิดถึงผลลัพธ์ที่จะตามมาด้วย และเตรียมตัวรับมือกับแรงปะทะของการเปลี่ยนแปลง
โดยทั่วไปแล้ว "การสร้างมักจะง่ายกว่าการต่อเติมเสมอ" แต่ ๆๆๆๆ เราจะต้องรู้ปัญหาแบบดั่งเดิมก่อนที่จะทำการสร้างใหม่ ยกตัวอย่าง
ระบบสตรีมทำให้เกิดปัญหาทั้ง Latency, Bandwidth, competency, High availability กำลังอธิบายว่าเราไม่จำเป็นต้องเริ่มจาก Zero แต่ให้เริ่มจากปัญหาที่เรามองว่าควรจะจัดการอะไรบางแยกออกจากกัน
แต่ต้องเข้าใจว่าการทำสิ่งที่เรากำลังทำมีความท้าทายได้แก่
- จัดทีม เนื่องจากการทำในสิ่งนี้เป็นต้นทุนที่ค่อนข้างสูง ดั่งคำที่ว่า ของเก่าก็ต้องดูแล ของใหม่ก็ต้องสร้าง
- แนวคิดและการฝึกฝนเรียนรู้ DDD เนื่องด้วยการทำงานสิ่งนี่ จะไม่ได้อาศัยเราคนใดคนนึง แต่อาศัยทีมและการเป็นนักพัฒนาแบบมืออาชีพเราทำงานเป็นทีม ดังนั้นทีมเราต้องเข้าใจและเรียนรู้ไปด้วยกัน
- ประเมินสถานะการณ์ของโครงการขายของออนไลน์ ไม่ใช่ทุกธุรกิจพร้อมที่จะเปลี่ยนแปลงทันที
- ต้นทุนที่มากขึ้น เราต้องเข้าใจและยอมรับว่าการจะทำของที่ดีขึ้น เป็นไปไม่ได้เลยที่จะไม่มีสิ่งที่ต้องเพิ่มขึ้น
- หากนี้เป็นครั้งแรกของทีม จงระวังความไม่แน่นอน ที่อาจจะเกิดขึ้นกับเราและทีมของเราได้
Architechture เป็นปัญหาจนมาถึงจุด วิกฤต ใช่หรือไม่
ไม่มีใครรู้ดีเท่าผู้สร้างสิ่งนี่ หากจะถามก็คงต้องกลับมามองที่ตัวเราก่อนว่า เรานำพาเทคโนโลยีรวมถึงการจัดการซอฟต์แวร์มาถึงจุดของปัญหาเพียงเพราะ Architechture จริง ๆ หรือยัง
หรือว่าเรามีการจัดการซอฟต์แวร์ยังไม่ดีพอ Software Crisis เช่น
- Resource เกินจำเป็นสิ้นเปลือง
- ซอฟต์แวร์ไม่มีประสิทธิภาพมาก
- ซอฟต์แวร์คุณภาพต่ำกว่ามาตรฐาน
- ซอฟต์แวร์มักไม่เป็นไปตามข้อกำหนด ออกแบบอย่างได้อีกอย่าง
- จัดการยากและดูแลรักษายาก
- ส่งมอบซอฟต์แวร์ล่าช้า
ควรยึดมั่นเพียงแค่ DDD หรือไม่
เราเรียนรู้ที่จะมองเห็นวิธีทางในการนำ Architechture มาใช้กับเราอย่างไรและทีมของเราในธุรกิจนั้น ๆ เช่น หากเรามีผู้รับเหมาที่ทำได้แค่อย่างเดียวกับผู้รับเหมาที่ทำได้หลากหลาย เราก็เลือกโอกาสที่จะให้ผู้รับเหมาทำได้หลากหลายมากกว่า เช่นเดียวกันกับ Architechture เราควรที่จะรู้จักผสมผสาน นำแนวคิดมาใช้ รวมถึงกระบวนการจัดการ การเขียนโปรแกรม และการทำงานร่วมกัน ในหลากหลายแขนง
ยกตัวอย่างการผสมผสาน
- Architechture นำ DDD มาใช้
- Process นำ Agile มาใช้
- Codeing นำ Extreme Programming มาใช้
- Team management นำ Lean startup มาใช้
หากในการประเมินสถานการณ์แล้วเรามองว่าทีมเราเหมาะสมกับการนำ Architechture DDD มาใช้แล้ว แปลว่าเราเตรียมพร้อมและวางแผนไว้แล้ว
หากแต่ว่าเรายังไม่มั่นใจ และประเมินแล้วเรามีหลากหลายสิ่ง เป็นขอบเขตให้เราไม่สามารถนำ Architechture DDD มาใช้ได้ ไม่ต้องเสียใจไป สถานการณ์ที่เราอยู่ยังไม่ถึงเวลา
หากท่านชอบและรู้สึกว่ามีประโยชน์ รบกวนแชร์และแบ่งปันให้ผู้ที่สนใจและควรจะได้รับการเข้าถึงบทความนี้ แล้วพบกันใหม่ครับ