Common Risks (ความเสี่ยงที่พบบ่อย)

เป้าหมายหลักของ pipeline architecture คือการแยกฟังก์ชันการทำงานออกเป็น filter ที่มีจุดประสงค์เดียว โดยแต่ละ filter ทำหน้าที่ หนึ่ง อย่างกับข้อมูลแล้วส่งต่อให้ filter อื่นประมวลผลต่อ ดังนั้นความเสี่ยงที่พบบ่อยที่สุดอย่างหนึ่งคือการยัดความรับผิดชอบมากเกินไปให้กับ filter การกำกับดูแล (governance) ที่ดี ซึ่งเราจะกล่าวถึงในหัวข้อถัดไป ช่วยให้ทีมลดความเสี่ยงนี้ได้ด้วยการระบุจุดประสงค์เบื้องหลัง filter component แต่ละตัวให้ชัดเจน

ความเสี่ยงที่พบบ่อยอีกอย่างหนึ่งของ architecture style นี้คือการเกิดการสื่อสารแบบสองทิศทาง (bidirectional) ระหว่าง filter pipe ถูกออกแบบมาให้เป็น ทางเดียวเท่านั้น เพื่อแยก concern ระหว่าง filter ให้ชัดเจนและป้องกันไม่ให้ filter ทำงานร่วมกัน (collaboration) ถ้าพบว่าจำเป็นต้องมีการสื่อสารแบบสองทิศทาง นั่นเป็นสัญญาณที่ดีว่า pipeline architecture อาจไม่ใช่ style ที่เหมาะสมสำหรับกรณีนี้ หรือ filter มีความซับซ้อนเกินไป ฟังก์ชันการทำงานถูกแบ่งขอบเขตไม่ถูกต้อง

การจัดการเงื่อนไข error เป็นความซับซ้อนอีกอย่างที่อาจนำมาซึ่งความเสี่ยงสูงใน architectural style นี้ ถ้าเกิด error ขึ้นภายใน pipeline มักยากที่จะระบุว่าควรออกจาก pipeline อย่างไรและกู้คืนได้อย่างไรเมื่อ pipeline เริ่มทำงานไปแล้ว ด้วยเหตุนี้ สถาปนิกจึงควรระบุเงื่อนไข error ร้ายแรงที่เป็นไปได้ทั้งหมดภายใน pipeline ก่อนที่จะกำหนด architecture

พื้นที่ความเสี่ยงสุดท้ายคือการจัดการ contract ระหว่าง filter แต่ละ pipe มี contract ที่แทนข้อมูล (และอาจรวมถึง type ที่เกี่ยวข้อง) ที่จะส่งไปยัง filter ถัดไป การเปลี่ยน contract ระหว่าง filter ต้องมี governance และการทดสอบที่เข้มงวดเพื่อให้แน่ใจว่า filter อื่นที่รับ contract นี้จะไม่พัง