จากที่พูดคุยกันเรื่องการออกแบบ service
ว่าแต่ละ service นั้น
มักจะมี coupling หรือผูกมัดกับ depedency อื่น ๆ ไม่ว่างทางใดก็ทางหนึ่ง
ดังนั้นเราควรพยายามลด coupling เหล่านั้นลง
จาก tight coupling มาเป็น loose หรือ no coupling ไปเลยจะยิ่งดี
มิเช่นนั้น อาจจะเกิด Distributed Monolith ขึ้นมาแทนก็ได้
ดังนั้นมาดูกันหน่อยว่า coupling ในการออกแบบ service มีเรื่องอะไรบ้าง ?
- Database coupling คือ ที่จัดเก็บข้อมูลจะ share กัน หรือจะแยก ซึ่งทั้งคู่ก็มีปัญหาของมันไป
- Communication coupling คือการติดต่อสื่อสารจะเป็นแบบ sync หรือ async หรือจะใช้แบบ pull/push ซึ่งบ่อยครั้งจะเจอแบบ sync ต่อกันไปเรื่อย ๆ คำถามคือ แยกออกมาทำไม มีปัญหาเยอะไหม ตรงนี้ต้องคิด ไม่ใช่ว่าไม่ดีนะ แต่ต้องใช้ให้เหมาะสม
- Code coupling คือ มีบางส่วนงานที่มี logic การทำงานเหมือนกัน เรามักจะเรียกว่า common code หรือ reuse code ดังนั้นทำเป็น library แล้ว share กันไปใช้งานในทุก ๆ service แบบนี้ดีไหมนะ ?
- Test Environment coupling คือชอบใช้ environment เดียวกัน deploy ที่เดียวกัน ทดสอบที่เดียวกับ database เดียวกัน ปัญหาตามมาอีกเพียบไหมนะ
- Domain coupling คือแยกกันตาม domain หรือการทำงานไปแล้ว แต่ก็ยังเรียกใช้งานกันข้าม domain คำถามคือ สิ่งที่ return กลับมา ยังเป็นข้อมูลที่ผูกติดกับ doamin นั้น ๆ ไหม ถ้าใช่มันส่งผลไหม เมื่อมีการเปลี่ยนแปลงจากภายใน ถ้าใช่ต้องรวังเรื่องของ encapsulation ของ data ให้ดี หรือ return กลับเท่าที่จำเป็นเท่านั้น
