ตอนนี้เราจะเจาะลึกรายละเอียดของการออกแบบเชิงโครงสร้าง (structural design) ซึ่งเป็นหนึ่งในบทบาทหลักของสถาปนิกซอฟต์แวร์ กิจกรรมนี้ประกอบด้วยสองส่วนหลัก ๆ ได้แก่ architectural characteristics analysis ซึ่งเป็นเนื้อหาของบทนี้ และ logical component design ซึ่งกล่าวถึงใน Chapter 8 สถาปนิกสามารถทำสองกิจกรรมนี้ในลำดับใดก็ได้ (หรือแม้แต่ทำคู่ขนานกัน) แต่ทั้งสองจะมาบรรจบกันที่จุดเชื่อมสำคัญจุดหนึ่ง

เมื่อบริษัทหนึ่งตัดสินใจแก้ปัญหาบางอย่างด้วยซอฟต์แวร์ บริษัทจะรวบรวมรายการข้อกำหนด (requirement) สำหรับระบบนั้น (มีเทคนิคมากมายในการดึงข้อกำหนดเหล่านี้ออกมา ซึ่งกล่าวถึงใน Chapter 8 ) เราจะเรียกข้อกำหนดเหล่านี้ว่า problem domain (หรือเรียกสั้น ๆ ว่า domain ) ตลอดทั้งเล่ม คุณได้เรียนรู้ใน Chapter 1 แล้วว่า architecture characteristics คือแง่มุมสำคัญของระบบที่เป็นอิสระจาก problem domain แต่มีความสำคัญต่อความสำเร็จของระบบ ในบทนี้เราจะเจาะลึกลงไปในการนิยามคำนี้ รวมถึง architectural characteristics แบบเฉพาะเจาะจงด้วย

สถาปนิกมักร่วมมือกันนิยาม domain แต่ก็ต้องนิยาม ค้นหา และวิเคราะห์ทุกสิ่งที่ซอฟต์แวร์ต้องทำ ซึ่งไม่ได้เกี่ยวข้องโดยตรงกับฟังก์ชันของ domain นั่นคือ architectural characteristics บทบาทของสถาปนิกในการนิยาม architectural characteristics เป็นส่วนหนึ่งที่ทำให้สถาปัตยกรรมซอฟต์แวร์แตกต่างจากการเขียนโค้ดและการออกแบบทั่วไป สถาปนิกยังต้องพิจารณาปัจจัยอื่น ๆ อีกมากมายในการออกแบบโซลูชันซอฟต์แวร์ ดังแสดงใน Figure 4-1

Requirements

Figure 4-1. โซลูชันซอฟต์แวร์หนึ่งประกอบด้วยทั้ง domain requirement และ architectural characteristics