Image may be NSFW.
Clik here to view.
Clik here to view.
ในการแบ่งระบบงานออกเป็น service ย่อย ๆ นั้น
ไม่ว่าจะแบ่งตามอะไรก็ตาม มักจะมีประเด็นเรื่องของ share หรือ reuse กันทั้งนั้น
บ้างก็ว่าเพื่อลดการทำงานลงไป
บ้างก็ว่าเพื่อลดค่าใช้จ่ายของการพัฒนาลงไป
และมักจะลงท้ายด้วยปัญหาต่าง ๆ มากมาย
ทั้ง service นั้นใหญ่เกินไป
ทั้งเมื่อแก้ไขแล้วกระทบส่วนต่าง ๆ ทั้งรู้และไม่รู้
ทำให้การดูแลรักษายาก หรือ เพิ่มสิ่งใหม่ ๆ ข้าไปก็ยาก
ดังนั้นมาดูกันหน่อยว่า มีอะไรควรระวังบ้าง ?
เพื่อไม่ให้ซ้ำรอยเดิมกันอีก
เรื่องที่เจอบ่อย ๆ คือ การใช้ซ้ำที่มีรูปแบบแตกต่างกัน !!
ยกตัวอย่างเช่นระบบการส่ง OTP (One Time Password) ไปยัง email ของผู้ใช้งาน
ซึ่งการใช้งานจะเป็นแบบ 1:1 เสมอ
โดยมีการใช้งานได้ดี
แต่เมื่อมีระบบ email marketing เข้ามา
ทีมก็พบว่าเรามีระบบส่ง email อยู่แล้ว จึงน่าจะนำมาใช้งานได้เลย
แต่การส่งในแต่ละครั้งมีจำนวนเยอะมาก ๆ ตั้งแต่หลักร้อยถึงหลักล้าน email ต่อครั้ง
ดังนั้นจึงจำเป็นต้องแก้ไข ระบบส่ง email ให้รองรับการส่งจำนวนเยอะ ๆ
ทั้งรับข้อมูลแบบ bulk หรือ ครั้งละจำนวนมาก ๆ
ทั้งการสร้างระบบ messaging หรือ queue มารองรับการทำงาน
ซึ่งทำงานได้ดี
แต่เมื่อมีการส่ง email marketing จำนวนมาก ๆ
จะส่งผลต่อการส่ง OTP ไปยังผู้ใช้งานที่ล่าช้ามาก ๆ
ทำให้มีปัญหาต่อระบบงานหลัก
เนื่องจากทั้งสองระบบใช้ระบบส่ง email ร่วมกัน
นั้นคือ share หรือ reuse service นั่นเอง
ทำให้ต้องแก้ไขอีกรอบ ยกตัวอย่างเช่น
- กำหนด limit ของการส่ง email marketing ไว้ เพื่อลดผลกระทบ ทั้งจำนวนและเวลาที่ส่ง (Rate limiting)
- ทำการแยก service การส่งออกมา 2 service ตัวแรกส่ง OTP แบบ 1:1 เท่านั้น อีก service สำหรับ email marketing เท่านั้น
ดังนั้นลองกลับมาดูว่า การแยก service ของระบบงานที่เป็นอยู่นั้น
ใช้เหตุผลอะไรในการแบ่ง
และผลที่ได้มันส่งผลดีต่อระบบ, development และ business หรือไม่
หรืออีกเรื่องหนึ่งคือ ขอบเขตหน้าที่รับผิดชอบของ service ต้องชัดเจน
ไม่ควรนำ knowledge หรือ logic ของ service อื่น ๆ มาใส่ใน service ด้วย
มันทำให้เกิดข้อผูกมัดเยอะมาก ๆ หรือ tight couple
ส่งผลให้เมื่อมีการแก้ไข จะกระทบ หรือ แก้ไขเยอะมาก ๆ
แสดงดังรูป
Clik here to view.
ลองนำไปใช้งานกันดูครับ
คิดว่าน่าจะพอมีประโยชน์บ้าง
