Design Pattern ในการพัฒนาระบบโรงพยาบาล

สำหรับการพัฒนาระบบขึ้นมาสักระบบให้สอดคล้องกับรูปแบบธุรกิจ หรือกิจกรรมที่เกิดขึ้นภายใน อาจมีข้ออ้างที่เลี่ยงไม่ได้ว่าทีมพัฒนาที่ไม่ได้มีหลายคน แค่ 1-3 คน คงไม่ใช่เรื่องยากในการคุยเท่าไหร่ แต่ลองนึกว่าการพัฒนาไม่ได้จบแค่ 3 เดือน 6 เดือน แต่ยาวนานไปกว่านั้น คนที่มารับหน้าที่ต่อ ถ้าไม่รู้ว่าภาพรวมของระบบ หรือรูปแบบการพัฒนาเป็นอย่างไร ก็คงยากที่จะควบคุมคุณภาพของงานได้ เพราะต่างคนก็จะต่างทำในแบบของตนเองที่คิดว่าแก้ปัญหาได้นั่นเอง และเมื่อเวลาผ่านไปเป็นปี สองปี หรือนานกว่านั้น ถ้าต้องปรับ หรือเพิ่มฟีเจอร์ใหม่ ๆ ก็คงไม่ง่ายเท่าไหร่ นอกจากจะเขียนเทสต์ไว้ครอบคลุมทุกเคส

ดังนั้น การพัฒนาระบบหนึ่ง ๆ  นั้นมี Design Pattern ที่ค่อนข้างหลากหลายให้เลือกใช้ตามขนาดของระบบ ความซับซ้อน และรูปแบบการไหลของข้อมูลต่าง ๆ วันนี้เราเลยจะมายกตัวอย่างการเลือกใช้  Design Pattern ด้วยเคสของการพัฒนาระบบของโรงพยาบาลเพื่อรับมือกับปัญหาคนไข้ ซึ่งเข้ากับสถานการณ์ Covid-19 ช่วงนี้สักหน่อย

ออกตัวก่อนนะครับว่ามันอาจจะไม่ได้ดีที่สุด เป็นแค่วิธีการนำเสนอบางเคสของการใช้งาน Design Pattern ซึ่งแต่ละระบบ แต่ละงาน อาจจะปรับให้ดีกว่านี้ได้ตามคำแนะนำต่าง ๆ เพื่อปรับปรุงข้อมูลให้มีความเหมาะสมที่สุดครับ

ก่อนอื่นเริ่มที่การตั้งโจทย์กันก่อนว่า Journey ของคนไข้ที่ไปรับการรักษาที่โรงพยาบาล / สถานพยาบาล จะต้องเจออะไรบ้าง ดังนี้

1. ลงทะเบียนคนไข้ ในกรณีที่ไม่มีประวัติที่สถานพยาบาลนั้น ๆ
2. พยาบาลทำการซักประวัติ และตรวจ pre-screen (วัดอุณหภูมิ, ความดัน และอื่น ๆ)
3. รอคิวเข้าห้องตรวจ
4. เข้ารับทำการตรวจ
5. สุดท้ายจ่ายเงิน รอรับยากลับบ้าน 

^{ภาพรวมของระบบ}

ส่วนแรกที่เป็นสีส้มเราจะเรียกว่า "Client" คือ ส่วนที่ต้องมีการรับ Input ต่าง ๆ ตามกิจกรรมที่เกิดขึ้น

1. Nurse

แน่นอนว่าเมื่อมาถึงโรงพยาบาล คุณจะต้องลงทะเบียน และถูกทำการซักประวัติต่าง ๆ ก่อนที่จะได้พบหมอ เพื่อทำการ Pre-screen เบื้องต้นก่อนและเก็บประวัติลงในระบบ เพื่อไม่ให้เสียเวลาในห้องตรวจ

2. Doctor

เมื่อผ่านขั้นตอนที่หนึ่งเสร็จ ต่อไปคือการรับการตรวจรักษาจากหมอเฉพาะด้านนั้น ๆ ตามแต่อาการที่ผ่านการทำ Pre-screen ไปก่อนหน้า เพื่อที่จะได้ทำการส่งตัวไปให้หมอที่มีความถนัดต่อไป

3. Cashier

ในกรณีที่ไม่ได้เจ็บป่วยถึงขึ้นต้องนอนโรงพยาบาล ขั้นตอนถัดมาคุณต้องออกมาจ่ายเงินก่อน เพื่อรอรับยาตามอาการ ที่คุณหมอจัดให้ไปรับประทาน ซึ่งเป็นอันจบขั้นตอนการรักษา 

จากภาพใหญ่ของระบบจะเห็นว่าส่วนสีส้มจะเลือกใช้ Design Pattern แบบ DDD (Domain-Driven Design) แล้ว DDD คืออะไร ไปรู้จักกันเลย

DDD (Domain-Driven Design)

DDD จะมีขั้นตอนหลักๆ อยู่ 2 อย่างคือ Strategic design และ Tactical design 

Strategic Design

คือ การ design ภาพในมุมมองกว้าง ๆ ของระบบทั้งหมดเพื่อให้เห็นว่าระบบมีส่วนประกอบอะไรบ้างหลัก ๆ ที่ผู้ใช้งานจะต้องใช้ ซึ่งรายละเอียดจะไม่มีการพูดถึงในส่วนของ Technical แต่จะเป็นการพูดในภาพรวมของการทำงาน ซึ่งก็คือ Feature ต่าง ๆ นั่นเอง และแต่ละ Feature นั้นทำงานแบบไหน เพื่อตอบโจทย์อะไร ก่อนจะลงรายละเอียดในขั้นตอนต่อไป

Tactical design

คือ การนำระบบที่ได้จากการทำ Strategic Design ที่ผ่านการถกกันมาแล้ว นำมาทำการ design ภายในตัว Core Domain เพื่อแจกแจงการทำงานและข้อมูลทั้งหมดภายใน domain ออกมา ว่าแต่ละ domain จะออกแบบสำหรับการทำงานอย่างไร แตกย่อยออกเป็นแบบไหนให้เหมาะกับรูปแบบการใช้งานของ Feature นั้น ๆ ออกเป็น Boundary Context ซึ่ง Context เหล่านี้จะมีขอบเขตการทำงานที่ชัดเจน

แต่ในระบบใหญ่นั้นก็จะมี Feature ที่เป็นแบบ 'Nice to have' กับ 'Must have' ซึ่งตัวที่เป็น Nice to have ดันมีเยอะแยะเต็มไปหมด เพราะคนส่วนใหญ่มองว่าถ้ามีสิ่งนี้ จะช่วยทำให้ User มีความสุขกับการใช้งาน ง่ายขึ้น ดีขึ้น ดังนั้น สิ่งที่ควรจะต้องทำอย่างแรกคือการสนใจ Feature ที่เป็น Must have ก่อน เพราะเป็นส่วนที่สำคัญที่สุด และทำให้ Flow สามารถไหลต่อไปยังส่วนต่าง ๆ ได้ดีนั่นเอง ซึ่งการพัฒนาก็ไม่ได้ตายตัว แล้วแต่ความถนัดของทีมด้วย เพื่อความรวดเร็วและสามารถส่งงานให้ได้ทันตามกำหนด

เกร็ดน่ารู้ : การพูดคุยกันระหว่าง Business กับ Technical เราจะใช้ภาษาที่เป็นกลางในการสื่อสาร ซึ่ง DDD เรียกว่า "Obiquitous language"

ติดตามอ่านบทความดี ๆ ที่น่าสนใจ ไม่ว่าจะเป็น Machine Learning, Startup, Design, Software Development และ Management ทาง Senna Labs Blog ได้ทุกวัน