Design Versus Architecture and Trade-Offs (การออกแบบเทียบกับสถาปัตยกรรม และ Trade-off)

ใน kata ของ Silicon Sandwiches คุณคงจะระบุ customizability ว่าเป็นส่วนหนึ่งของระบบ แต่คำถามต่อมาคือ มันควรเป็นสถาปัตยกรรมหรือการออกแบบ? สถาปัตยกรรมบ่งบอกถึง component เชิงโครงสร้างบางอย่าง ในขณะที่การออกแบบอยู่ภายในสถาปัตยกรรม สำหรับ Silicon Sandwiches คุณอาจเลือกใช้ architecture style อย่าง microkernel และสร้างการรองรับเชิงโครงสร้างสำหรับการปรับแต่ง อย่างไรก็ตาม หากคุณเลือกสไตล์อื่นเพราะมีประเด็นที่แข่งขันกัน นักพัฒนาก็สามารถ implement การปรับแต่งได้ด้วย design pattern แบบ Template Method ซึ่งอนุญาตให้คลาสแม่นิยาม workflow ที่คลาสลูกสามารถ override ได้ ตัวเลือกไหนดีกว่ากัน?

เหมือนทุกอย่างในสถาปัตยกรรม—มันขึ้นอยู่กับสถานการณ์ ก่อนอื่น มีเหตุผลดี ๆ ที่จะ ไม่ implement สถาปัตยกรรมแบบ microkernel หรือไม่ (เช่น performance และ coupling)? ประการที่สอง architectural characteristics อื่น ๆ ที่พึงประสงค์ทำได้ยากกว่าในการออกแบบแบบใดแบบหนึ่งหรือไม่? ประการที่สาม การรองรับ architectural characteristics ทั้งหมดในสถาปัตยกรรมเทียบกับในการออกแบบจะมีต้นทุนต่างกันแค่ไหน? การวิเคราะห์ trade-off แบบนี้เป็นส่วนสำคัญของบทบาทสถาปนิก

เหนือสิ่งอื่นใด สิ่งสำคัญคือต้องร่วมมือกับนักพัฒนา ผู้จัดการโปรเจกต์ ทีม operation และผู้ร่วมสร้างระบบซอฟต์แวร์คนอื่น ๆ ไม่ควรตัดสินใจด้านสถาปัตยกรรมใด ๆ โดยแยกออกจากทีม implementation (ซึ่งจะนำไปสู่ antipattern Ivory Tower ที่น่ากลัว) ในกรณีของ Silicon Sandwiches สถาปนิก tech lead นักพัฒนา และนักวิเคราะห์ domain ควรร่วมมือกันตัดสินใจว่าจะ implement customizability ได้ดีที่สุดอย่างไร

คุณไม่ควรเครียดมากเกินไปกับการหาชุด architectural characteristics ที่ถูกต้องเป๊ะ นักพัฒนาสามารถ implement ฟังก์ชันได้หลายวิธี อย่างไรก็ตาม การระบุองค์ประกอบเชิงโครงสร้างที่สำคัญได้อย่างถูกต้องอาจช่วยให้ได้การออกแบบที่เรียบง่ายหรือสง่างามยิ่งขึ้น คุณสามารถออกแบบสถาปัตยกรรมที่ไม่รองรับ customizability เชิงโครงสร้าง แต่ให้การออกแบบของแอปพลิเคชันเองรองรับพฤติกรรมนั้นแทนก็ได้ (ดูที่ “Design Versus Architecture and Trade-Offs” ) จำไว้ว่า ไม่มีการออกแบบที่ดีที่สุดในสถาปัตยกรรม มีแต่ชุดการ trade-off ที่แย่น้อยที่สุดเท่านั้น

ให้จัดลำดับความสำคัญของ architectural characteristics เหล่านี้เมื่อพยายามหาชุดที่จำเป็นน้อยที่สุด เมื่อทีมได้ลองระบุ architectural characteristics ในรอบแรกแล้ว แบบฝึกหัดที่มีประโยชน์คือการลองหาตัวที่สำคัญน้อยที่สุด ถ้าคุณต้องตัดออกหนึ่งตัว จะเป็นตัวไหน? โดยทั่วไปแล้ว สถาปนิกมักจะตัด explicit architectural characteristics ออกมากกว่า เพราะ implicit หลายตัวสนับสนุนความสำเร็จโดยรวมอยู่แล้ว วิธีที่เรานิยามว่าอะไรสำคัญหรือจำเป็นต่อความสำเร็จ ช่วยตัดสินได้ว่าแอปพลิเคชัน ต้องการจริง ๆ หรือไม่สำหรับแต่ละ architectural characteristic การพยายามหาตัวที่เกี่ยวข้องน้อยที่สุดสามารถช่วยให้คุณตัดสินความจำเป็นที่สำคัญได้

ในกรณีของ Silicon Sandwiches architectural characteristic ตัวไหนที่เราระบุไว้สำคัญน้อยที่สุด? เช่นเคย ไม่มีคำตอบที่ถูกต้องแบบสัมบูรณ์ อย่างไรก็ตาม ในกรณีนี้ โซลูชันอาจสูญเสีย customizability หรือ performance ไปก็ได้ เราอาจตัด customizability ออกจากการเป็น architectural characteristic และวางแผน implement พฤติกรรมนั้นเป็นส่วนหนึ่งของการออกแบบแอปพลิเคชันแทน จาก operational architectural characteristics ทั้งหมด performance น่าจะสำคัญน้อยที่สุดต่อความสำเร็จ แน่นอนว่านั่นไม่ได้หมายความว่านักพัฒนาตั้งใจจะสร้างแอปพลิเคชันที่มี performance แย่ มันแค่หมายความว่าการออกแบบนี้ไม่ได้ให้ความสำคัญกับ performance มากกว่าคุณลักษณะอื่น ๆ เช่น scalability หรือ availability