The Orphaned Service (เซอร์วิสไร้เจ้าของ)

แล้วเซอร์วิสที่ไม่มีใครดูแลอย่างจริงจังอีกต่อไปล่ะ? เมื่อเราเคลื่อนไปสู่สถาปัตยกรรมที่ละเอียดขึ้น ตัวไมโครเซอร์วิสเองก็เล็กลง หนึ่งในข้อดีของไมโครเซอร์วิสขนาดเล็ก อย่างที่เราพูดถึงไปแล้วคือความเรียบง่าย ไมโครเซอร์วิสที่เรียบง่ายกว่าและมีฟังก์ชันการทำงานน้อยกว่าอาจไม่จำเป็นต้องเปลี่ยนแปลงไปสักพักใหญ่ ลองพิจารณาไมโครเซอร์วิส Shopping Basket ธรรมดาๆ ที่มีความสามารถค่อนข้างพื้นฐาน: เพิ่มลงตะกร้า ลบออกจากตะกร้า และอื่นๆ เป็นไปได้มากทีเดียวที่ไมโครเซอร์วิสนี้อาจไม่ต้องเปลี่ยนแปลงเลยเป็นเวลาหลายเดือนหลังจากเขียนขึ้นครั้งแรก แม้ว่าการพัฒนาที่กระตือรือร้นในส่วนอื่นๆ จะยังดำเนินต่อไปก็ตาม จะเกิดอะไรขึ้นตรงนี้? ใครเป็นเจ้าของไมโครเซอร์วิสนี้?

ถ้าโครงสร้างทีมของคุณสอดคล้องกับ bounded context ขององค์กรของคุณ แม้แต่เซอร์วิสที่ไม่ค่อยเปลี่ยนแปลงบ่อยก็ยังมีเจ้าของโดยพฤตินัยอยู่ ลองนึกภาพทีมที่สอดคล้องกับ context การขายบนเว็บสำหรับผู้บริโภค ทีมนี้อาจดูแล user interface บนเว็บและไมโครเซอร์วิส Shopping Basket กับ Recommendation แม้ว่า cart service จะไม่ถูกเปลี่ยนแปลงมาหลายเดือนแล้ว ตามธรรมชาติแล้วก็ยังตกเป็นหน้าที่ของทีมนี้ที่จะทำการเปลี่ยนแปลงถ้าจำเป็น หนึ่งในประโยชน์ของไมโครเซอร์วิส แน่นอนว่าคือ ถ้าทีมต้องเปลี่ยนแปลงไมโครเซอร์วิสเพื่อเพิ่มฟีเจอร์ใหม่และไม่พอใจกับฟีเจอร์ที่มีอยู่ การเขียนมันขึ้นใหม่ก็ไม่ควรใช้เวลานานเกินไป

ถึงกระนั้น ถ้าคุณใช้แนวทาง polyglot อย่างแท้จริงและใช้ tech stack หลากหลาย ความท้าทายในการเปลี่ยนแปลงเซอร์วิสไร้เจ้าของก็อาจยิ่งซับซ้อนขึ้น ถ้าทีมของคุณไม่รู้จัก tech stack นั้นอีกต่อไป