DDD แบบ Roof ๆ Dยังไง
ผมเห็นคลาส DDD ของพี่ Twin Panichsombat มาสักระยะ เห็นคนส่วนใหญ่ไปเรียนก็จะเป็น Dev หรือ คนที่เป็น SA, SE, Tech Lead เป็นส่วนใหญ่ ในใจก็กล้าๆ กลัวๆ ว่าเราจะไปเรียนรู้เรื่องไหมนะ เราไม่ได้เขียน Code เราไม่ได้ออกแบบอะไรเลยนะ เป็นแค่ Agile Coach ธรรมดา
แล้วโอกาสก็มาถึง พี่รูฟ เปิดคลาสแบบ Publish เลยพยายามสมัครไป ส่ง Profile เป็นจะสมัครงานเลย แล้วก็ได้รับเลือกเรียนสมใจอยาก พร้อมลงทุกเสียตังค์ไปหละคราวนี้
“Why DDD?”
จะตอบว่ามันเก๋ มันเทห์ ก็ได้ แต่จริงๆ แล้วมันเป็นเรื่องใกล้ตัวเรามา ใน Software Development Architecture and Design Trend ได้พูดถึงเรื่อง DDD และ Microservices ว่าเป็นอะไรที่ถูกเอามาใช้กันอย่างแพร่หลายแล้วนะเฟ้ย ไม่ได้อยู่ในช่วงทดลอง ช่วงคนกำลังเห่อ แต่มันเป็นอะไรที่หลายๆ ที่ หลายคนเอามาใช้กันจนเรียกได้ว่า “เฟิร์ม” แล้วนะแหละ
อีกอย่างคือพอเราพูดถึงการทำ DDD ก็จะไม่พูดถึงการทำ MicroService ไม่ได้ เพราะเป็นอะไรที่หลายๆที่ พูดถึงและทำมันอยู่ มันเป็นเรื่องที่เกี่ยวข้องกัน ว่ากันซื่อๆ ตามความเข้าใจผมคือ ถ้าจะแบ่ง Microservice ได้ดี ก็เริ่มมาจากการเข้าใจ และออกแบบ DDD ได้ดี พอเราออกแบบ Domain ได้ดี เราก็จะแบ่ง Microservice ได้ดี แบบที่ ไม่ใช่มี Microservice แต่ยังรู้สึกถึง Monolith.
พูดมาถึงตรงนี้มันมีแต่ของดีของฝั่ง Tech ฝั่ง Dev หมดเลยนี่น่า ก็ต้องบอกว่า ไม่ใช่เด้อออ เวลาเราออกแบบอะไรสักอย่างโดยเฉพาะ Software เราจะแบ่งคนออกเป็นสองพวก
- Problem Space คนที่มาพร้อมกัน ปัญหา มีสิ่งที่อยากได้ อยากแก้ปัญหาให้กับ User อยากทำให้ชีวิตดีชึ้น อยากทำให้โลกดีขึ้น
- Solution Space ฝั่งนี้ส่วนใหญ่เป็น Tech คนที่มีประสบการณ์ในการทำของมาอย่างช่ำชอง เวลาใครเดินมาพร้อมกับปัญหาคนเหล่านี่จะมี Solution ในใจไว้แล้วตลอดเวลา เรียกว่าพอ user บอกปัญหา คนTech จะเห็นวิธีการล่วงหน้าไว้แล้วว่าต้องทำท่าไหน
ทีนี้มันเป็นไปได้มากเลยที่เราเข้าใจไม่ตรงกันเพราะ Gap ระหว่าง Problem Space และ Solution Space มันห่างไกลกันมาก Business ไม่รู้เรื่อง Tech และ Tech ไม่เข้าใจกระบวนการทาง Business ที่แท้จริง หลายครั้งเราจะพบกับ Solution ที่อลังฝั่งTech แต่ไม่ได้ประโยนช์อะไรให้Business เลย หรือ มีทุก Function ฝั่ง Business แต่ Tech Dept กระจุยกระจาย ใช้แล้วสักพักก็พัง
เพราะฉะนั้น การออกแบบ Software ที่ดี ต้องมองแบบ Holistic view ความต้องการเชิง Business ที่จะสร้าง Impact ไปที่ user ควบคู่ไปกับ การออกแบบ architecture ที่รอบรับ Business ณ ช่วงเวลานั้น สำคัญมากที่สุดที่ทุกคนทุกฝ่ายเข้าใจตรงกัน และ ตกลงที่จะทำด้วยวิธีเดียวกัน
DDD Key Concepts
การออกแบบ DDD มี Concept หลักอยู่ 3 อย่าง
- What is Domain
- Bounded Context
- Ubiquitous Language
การจะทำ DDD เราก็ต้องมาหาก่อนว่า มี Domain อะไรบ้าง โดยใน Workshop นี้ พี่รูฟใช้ User story (User Journey) นั่นเอง ซึ่ง วิธีการก็คือ
- มีใครที่เกี่ยวข้องบ้าง เริ่มต้องจากเราต้องหา Domain Expert ก่อน คนที่เข้าใจกระบวนการต่างๆ ผู้ที่ได้ลงมือจริงเห็นจริงๆ เช่นจากตัวอย่างเราจะทำเรื่องเกี่ยวกับโรงพยาบาล เพราะฉะนั้น Domain expert ก็จะมี พนักงานต้อนรับ, หมอ, พยาบาล, เภสัช, แคชเชียร์, etc.
- ถ้าพูดถึงการมาทำอะไรที่โรงพยาบาลมี Journey อะไรบ้างหละ เช่น ตั้งแต่มีคนไข้ไม่สบายมาหาหมอ เจอพนักงานต้อนรับถามอาการ ส่งตัวไปให้พยาบาล พยาบาลวัดไข้วัดความดันถามอาการ ส่งตัวเข้าห้องหมอ หมอตรวจอาการ หมอส่งไปตรวจLab พนักงานLab ตรวจLab หมออ่านผลตรวจและแจ้งอาการจ่ายยา พยาบาลพาไปห้องจ่ายยา ทำเรื่องจ่ายเงิน รับยา กลับบ้าน. ทำออกมาเป็น User Journey แบบตัวอย่างรูปด้านล่างที่ผมเอามาจากคนที่เรียนท่านหนึ่งครับ
3. จาก User Flow นี้ เราจะพบว่าสิ่งที่ทำให้เราแยก Domain ได้คือ ชื่อเรียกของ User ในแต่ละ Stage ต่างกัน เช่น ตอนเจอพนักงานต้องรับเป็น ลูกค้า พอมาเจอพยาบาลและหมอกลายเป็น คนไข้ พอมาเจอกับแคชเชียร์ กลายเป็น ลูกหนี้ พอเห็นแบบนี้เราจะเห็นได้ว่า จาก Journey เราสามารถแบ่ง Domain ได้ตาม Stage ของ User ที่เปลี่ยนไป
หลักจากนั้นเราจะมาแบ่ง Domain ของเรากัน
Core คือ สิ่งที่เราควรลงทุนมากที่สุด เช่น ใส่ใจรายละเอียดมันมากที่สุด, ใช้ทีมที่ดีที่สุด, Budget เยอะที่สุด เพราะ มันคือ หัวใจ ของธุรกิจ
Generic คือ สิ่งที่เราสามารถซื้อมาใช้งานได้หรือจะเรียกว่าใครๆก็มี และไม่ควรลงแรงกับมันมาก เช่น ระบบ CRM, ระบบ Finance
Supporting คือ สิ่งที่เราสามารถ Implement เองได้ แต่ไม่ค่อยมีน้ำหนักความสำคัญเท่า Core Subdomain เพราะหน้าที่หลักของมันคือการสนับสนุนการทำงานของ System
Core Domain เปลี่ยนแปลได้ตลอดเวลาตาม ธุรกิจของเราที่มีการปรับเมื่อ Core หลักของธุรกิจเราเปลี่ยนไป ดูตัวอย่างจาก RS หรือ เต่าบิน ได้ว่าเค้ามีการปรับ Core ธุรกิจมาอย่างไรตั้งแต่ก่อตั้งบริษัท
จากตัวอย่าง Core ที่สำคัญของ Domain โรงพยาบาลคือ การรักษา เพราะฉะนั้น ช่องที่ User เป็นคนไข้ คือช่วงที่จะเป็น Core Domain ส่วนอื่นก็จะถูกแยกออกมาเป็น Supporting คือ ช่วงจ่ายยา และ Generic เป็นช่วง CRM ของพนักงานต้อนรับ
เมื่อเราแบ่ง Domain แล้ว ต่อไปที่ต้องทำคือ แล้วระหว่าง Domain ต่างๆ จะรับส่งอะไรกัน ต้องการข้อมูลอะไรจากกันบ้าง โดยที่มองว่า Core Domain ต้องมีข้อมูลที่สำคัญที่สุด และ เพียงพอที่จะอยู่ได้โดยไม่ต้องพึ่งพาคนอื่น แบบว่า ระบบอื่นล่ม ตูอยู่ได้ไม่พัง นั่นเอง การวางแผนความสัมพันธ์เพื่อ รับ (Downstrem) — ส่ง (Upstream) ข้อมูลระหว่าง Bounded Context เราเรียกกระบวนการนี้ว่า Context Map
ซึ่งก่อนหน้านั้น เราต้องมา Design กันก่อนว่า เราต้องการให้ Core Domain เรามีข้อมูลอะไรบ้าง โดยถามคำถามง่ายๆเช่น เราอยากเห็น Report อะไร หรือ เราอยากรู้อะไรใน Journey นี้บ้าง เช่น อยากรู้ระยะเวลาการใช้บริการ อยากรู้ ระยะเวลาการตรวจของหมอ อยากรู้ว่าลูกค้าเป็นโรคอะไรเยอะสุด จากคำถามพวกนี้จะทำให้เราลงรายละเอียดได้ว่า ถ้าอยากรู้เรื่องพวกนี้เราต้องมีข้อมูลอะไรบ้างหละ และข้อมูลพวกนั้นเรามีเองอยู่ล้ว หรือเราต้องไปเอาจาก SubDomain อื่นๆ แล้วเราก็ออกแบบว่าถ้าเราต้องไปเอามาจากคนอื่น เราต้องการให้รูปแบบความสัมพันธ์ของการดึงข้อมูลเป็นแบบไหน
การแยกเป็นความสัมพันธ์มีนี้
Cooperation
- Partnership คือ ความสัมพันธ์แบบ 1 : 1 ที่ทั้งคู่สามารถตกลงกันได้ว่าจะ รับ — ส่ง ยังไง
- Shared Kernel คือ ความสัมพันธ์แบบ ใช้อะไรสักอย่างร่วมกัน ซึ่งถ้ามีการเปลี่ยนแปลงจะส่งผลต่อทั้งสองฝั่งทันที
Customer-Supplier
- Conformist คือ ความสัมพันธ์ที่ ฝ่ายรับ ไม่มีอำนาจต่อรองและต้องใช้แค่สเปคที่ ฝ่ายส่ง ส่งมาเท่านั้น
- Anti Corruption Layer (ACL) คือ ความสัมพันธ์แบบเดียวกับ Conformist แต่ต่างกันตรงที่ ฝ่ายรับ จะมี Intermediate Layer หรือ Middleware เพื่อใช้ติดต่อกับ ฝ่ายส่ง
- Open-Host Service คือ ความสัมพันธ์ตรงข้ามกับ ACL ซึ่ง ฝ่ายส่ง จะสร้าง Standard บางอย่าง เพื่อใช้ติดต่อกับ ฝ่ายรับ
Separate Ways
คือ ความสัมพันธ์ที่แต่ละ Bounded Context แยกขาดกัน เธอมีท่าไหนก็เรื่องของเธอ ฉันก็จะมีของฉัน ไว้ค่อยหาทางมา Sysc กัน
จากนั้นเพื่อให้ออกแบบได้ดีขึ้นและเห็นภาพลึกขึ้นเราก็ควรทำต่อว่า ถ้าพูดถึง Journey ใน Core Domain มันจะออกมาเป็น WireFrame หน้าตา (หน้าจอ) แบบไหนกันนะ เพื่อที่เราจะได้เห็นภาพขัดขึ้นว่า เราต้องการข้อมูลอะไรบ้างที่จะแสดงออกมาเป็นหน้าจอนั้น เราต้องการ Imput Output อะไร, Flow ต้องเป็นแบบไหนบ้าง การส่งต่อข้อมูลต่างๆ และที่สำคัญ Ubiquitous Language
Ubiquitous Language ก็คือ ภาษาถิ่น หรือ ภาษากลาง ที่เมื่อเราใช้ ทุกๆฝ่ายจะเข้าใจตรงกัน ยกตัวอย่างเช่น ถ้าเราออกแบบระบบบางอย่างโดยแยกันทำ ฝั่ง Problem space จะมาด้วยภาษาทางการของเค้าเช่น Diagnose การตรวจโรค ซึ่งถ้าเราแยกกันทำทางฝั่ง Solution Sapce จะออกแบบมาง่ายๆ โดยใช้ตัวแปรประมาณ FunctionA. ซึ่งถ้าเรามีการทำ Unit Test เรามีการให้คนอื่นมาดู Code เรามีการ Review Code กับ User …..แล้วเราจะเข้าใจกันอย่างไรนะ
หลักจากได้ WireFrame เราก็มาออกแบบ Comand and Event ซึ่งตรงนี้จะช่วยให้เราสามารถเอาไปใช้ตอนเรา ออกแบบ Micorservice ได้ว่า ต้องมีอะไรบ้าง (เท่าที่ผมเข้าใจนะ)
Command Verb + Noun
Event Noun + Verb (Past tense)
หลักจากนั้นจะเป็นการหา Aggregate Levelโดยให้นึกภาพแต่ละหน้าจอเป็นแฟ้มข้อมูล เช่นหน้าจอ Login คือข้อมูล แฟ้มใบส่งตัว แล้วในแฟ้มนั้นต้องมีข้อมูลอะไรบ้างหละที่เรียกว่าใบส่งตัวต้องใช้
พอแยกออกมาได้ดังรูปนี้ ก็จะได้เป็น Aggregate Level ของใน Core Domain และ เจ้า Aggregate Level นี่แหละคือ Set ที่เล็กที่สุดที่จะเป็น Micorservice ได้ เล็กกว่านี้ไม่ได้แล้ว (ในหลักการของ DDD / Microservice ที่เราอ้างอิงนะ ถ้าใครไปตำราอื่นก็อาจจะเล็กได้อีก แต่เวลาเราออกแบบเราต้องยึดถือหลักการใดหลักการหนึ่งเพื่อให้เรามีเส้นที่จะตกลงกันได้)
พอถึงตรงนี้จริงๆ Business ตาลอยแล้วหละ 5555 เพราะหลังจากนี้คือไปออกแบบเชิง Software จริงๆ แล้ว แต่ว่าไม่ใช่ว่า Business อยู่ด้วยไม่ได้นะ เพราะ อะไรเพราะเราจะเห็นได้ว่า จาก Business requirment ที่ดูแสนธรรมดา สามารถขุดภาพเชิงลึกออกมาได้เป็นการออกแบบ Domain ที่ซับซ้อนขึ้น รู้ว่าต้องใช้ภาษาอะไร ต้องใช้ Database แบบไหน แล้วคนของเราทำได้ไหม
สิ่งสำคัญก็คือ เราต้องการให้ Business Fueature ทำงานได้ดีแค่ไหน มันขึ้นอยู่กับว่าเราออกแบบ Software เบื้องหลังได้ลึกแค่ไหน และ Business ตกลงที่จะให้เวลากับมันได้แค่ไหน เมื่อเราตกลงกันได้ ก็จะไม่มีการมาโทษกันว่า ก็พี่ให้เวลาไปเท่านี้แล้ว ทำไมระบบยังพังนะ อีกต่อไป …… หวังว่านะ
