Defining Software Architecture (การนิยาม Software Architecture)
แล้ว software architecture คืออะไรกันแน่ รูปที่ 1-1 แสดงให้เห็นว่าเราชอบคิดถึง software architecture อย่างไร คำนิยามนี้มีสี่มิติ software architecture ของระบบหนึ่งประกอบด้วย architecture style เป็นจุดเริ่มต้น ผสมกับ architecture characteristics ที่มันต้องรองรับ logical components ที่ใช้ implement พฤติกรรมของมัน และสุดท้ายคือ architecture decisions ที่ให้เหตุผลรองรับทั้งหมด โครงสร้างของระบบแสดงด้วยเส้นสีดำหนาที่รองรับ architecture ไว้ เราจะเดินผ่านมิติเหล่านี้อย่างรวดเร็วตามลำดับที่สถาปนิกวิเคราะห์มัน และบทถัดๆ ไปจะให้รายละเอียดเพิ่มเติม
Figure 1-1. Architecture consists of the system’s structure, combined with architecture characteristics (“-ilities”), logical components, architecture styles, and decisions
Architecture characteristics (ดู รูปที่ 1-2 ) นิยาม ความสามารถ (capability) ของระบบ (มักย่อว่า “-ilities”) และเกณฑ์ความสำเร็จของมัน กล่าวโดยย่อคือ ระบบ ควรทำ อะไร Architecture characteristics มีความสำคัญมากจนเราทุ่มเทหลายบทในหนังสือเล่มนี้เพื่อทำความเข้าใจและนิยามมัน
Figure 1-2. “Architecture characteristics” refer to the “-ilities” that the system must support
ในขณะที่ architectural characteristics นิยามความสามารถของระบบ logical components นิยาม พฤติกรรม ของมัน การออกแบบ logical component เป็นหนึ่งในกิจกรรมเชิงโครงสร้างที่สำคัญของสถาปนิก ใน รูปที่ 1-3 logical component ประกอบกันเป็น domain, entity และ workflow ของแอปพลิเคชัน
Figure 1-3. Logical components structure the behavior of the system
เมื่อสถาปนิกวิเคราะห์ architectural characteristic และ logical component ที่ระบบต้องการแล้ว (ทั้งสองอย่างจะอธิบายรายละเอียดในภายหลัง) พวกเขาก็รู้มากพอที่จะเลือก architecture style ที่เหมาะสมเป็นจุดเริ่มต้นสำหรับการ implement solution ของตน รูปที่ 1-4
Figure 1-4. Choosing an architectural style involves finding the easiest implementation path for a given set of requirements
มิติที่สี่ที่นิยาม software architecture คือ architecture decisions ซึ่งนิยามกฎว่าระบบควรถูกสร้างขึ้นมาอย่างไร ตัวอย่างเช่น สถาปนิกอาจตัดสินใจว่ามีเพียง Business layer และ Services layer ภายใน layered architecture เท่านั้นที่เข้าถึง database ได้ (ดู รูปที่ 1-5 ) โดยห้าม Presentation layer เรียก database โดยตรง Architecture decision ก่อตัวเป็นข้อจำกัดของระบบ และชี้นำทีมพัฒนาว่าอะไรทำได้และอะไรทำไม่ได้
Figure 1-5. Architecture decisions are rules for constructing systems
เราจะพูดถึง architecture decision และวิธีบันทึกมันอย่างกระชับใน บทที่ 21