The Spectrum Between Extremes (Spectrum ระหว่างสองขั้วสุดโต่ง)

ในฉบับพิมพ์ครั้งแรก เราระบุไว้เพียงสองกฎ อย่างไรก็ตาม เราค่อยๆ ตระหนักว่ามีกฎข้อที่สามอยู่

การตัดสินใจทางสถาปัตยกรรมส่วนใหญ่ไม่ใช่แบบ binary แต่อยู่บน spectrum ระหว่างสองขั้วที่สุดโต่ง

Third Law of Software Architecture

คงจะดีถ้าเราอยู่ในโลกที่มีการตัดสินใจแบบ binary ที่เรียบร้อยและชัดเจน แต่สถาปัตยกรรมซอฟต์แวร์ไม่ได้อยู่ในโลกแบบนั้น คนมักสังเกตว่ามันยากแค่ไหนที่จะให้คำนิยามที่ครอบคลุมสำหรับแนวคิดสำคัญในสถาปัตยกรรมซอฟต์แวร์ เช่น architecture กับ design, orchestration กับ choreography, topic กับ queue และอื่นๆ เหตุผลเบื้องหลังคือเกณฑ์การตัดสินใจไม่ใช่แบบ binary แต่อยู่บน spectrum ที่ค่อนข้างยุ่งเหยิง

ใน “Architecture Versus Design” เราได้พูดถึง spectrum ระหว่าง architecture กับ design และวิธีระบุว่าการตัดสินใจแบบใดแบบหนึ่งอยู่ตรงไหนใน spectrum นั้น อันที่จริง กฎข้อนี้ให้วิธีคิดที่มีประโยชน์เกี่ยวกับการตัดสินใจที่ใกล้ฝั่งสถาปัตยกรรมซอฟต์แวร์มากกว่าฝั่ง design ของ spectrum

การตัดสินใจทางสถาปัตยกรรมซอฟต์แวร์คือการตัดสินใจที่แต่ละตัวเลือกมี trade-off ที่สำคัญ

หากทุกอย่างในสถาปัตยกรรมซอฟต์แวร์ล้วนเป็น trade-off การตัดสินใจทางสถาปัตยกรรมก็ต้องมี trade-off สำหรับแต่ละตัวเลือกด้วย

ในฐานะสถาปนิก อย่าพยายามลดทอนทุกการตัดสินใจให้เป็นแบบ binary เพราะมันมีอยู่น้อยมากในโลกของเรา นั่นคือเหตุผลหนึ่งที่คำตอบของสถาปัตยกรรมซอฟต์แวร์ทุกข้อคือ “แล้วแต่กรณี” เพราะมันขึ้นอยู่กับว่าเกณฑ์ที่กำลังพิจารณาอยู่ตรงจุดไหนบน spectrum ของ solution ที่เป็นไปได้

ในฐานะสถาปนิก เราตัดสินใจอยู่ท่ามกลางความไม่แน่นอน การรับมือกับสิ่งนี้น่ารำคาญ แต่จำเป็น เราไม่เพียงบางครั้งต้องตัดสินใจสำคัญจากข้อมูลที่ไม่สมบูรณ์เท่านั้น แต่บ่อยครั้งการตัดสินใจก็ไม่ชัดเจนอยู่ดี แม้เราจะมีข้อมูลครบถ้วนก็ตาม เพราะมันอยู่ตรงจุดใดจุดหนึ่งบน spectrum ระหว่างสองขั้วสุดโต่ง

ยินดีต้อนรับสู่สถาปัตยกรรมซอฟต์แวร์!