What Is Software Architecture? (สถาปัตยกรรมซอฟต์แวร์คืออะไร)

หนึ่ง ในคำนิยามที่โด่งดังที่สุดของสถาปัตยกรรมซอฟต์แวร์มาจากอีเมลของ Ralph Johnson: "Architecture is about the important stuff. Whatever that is." 2 แล้วนี่หมายความว่าอะไรก็ตามที่สำคัญเป็นหน้าที่ของสถาปนิกใช่ไหม นั่นหมายความว่างานอื่นๆ ที่ทำอยู่ ไม่ สำคัญเลยหรือ ปัญหาของคำพูดที่ถูกอ้างถึงบ่อยนี้คือมันมักถูกใช้แบบตัดตอน โดยไม่เข้าใจบริบทที่ Ralph พูดไว้ทั้งหมด ก่อนอื่นเลย เห็นได้ชัดว่าเขาพูดในมุมมองของนักพัฒนาซอฟต์แวร์ เขาพูดต่อไปว่า:

ดังนั้น คำนิยามที่ดีกว่าคือ "ในโครงการซอฟต์แวร์ที่ประสบความสำเร็จส่วนใหญ่ นักพัฒนาผู้เชี่ยวชาญที่ทำงานในโครงการนั้นมีความเข้าใจร่วมกันเกี่ยวกับการออกแบบระบบ ความเข้าใจร่วมกันนี้เรียกว่า 'สถาปัตยกรรม' ความเข้าใจนี้รวมถึงวิธีที่ระบบถูกแบ่งออกเป็นคอมโพเนนต์ และคอมโพเนนต์เหล่านั้นมีปฏิสัมพันธ์กันผ่านอินเทอร์เฟซอย่างไร คอมโพเนนต์เหล่านี้มักประกอบขึ้นจากคอมโพเนนต์ย่อยๆ อีกที แต่สถาปัตยกรรมจะรวมเฉพาะคอมโพเนนต์และอินเทอร์เฟซที่นักพัฒนาทุกคน เข้าใจร่วมกัน เท่านั้น"

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

ในที่นี้ Ralph ใช้คำว่า components ในความหมายกว้างที่สุด ในบริบทของหนังสือเล่มนี้ เราสามารถคิดว่าคอมโพเนนต์คือไมโครเซอร์วิสของเรา และบางทีก็รวมถึงโมดูลภายในไมโครเซอร์วิสเหล่านั้นด้วย

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

สถาปนิกโดยเฉพาะคือคนที่ควรมองเห็นและเข้าใจระบบทั้งหมด เข้าใจแรงต่างๆ ที่กระทำต่อระบบ พวกเขาต้องมั่นใจว่ามีวิสัยทัศน์สำหรับสถาปัตยกรรมที่เหมาะสมกับวัตถุประสงค์และเป็นที่เข้าใจอย่างชัดเจน วิสัยทัศน์ทางสถาปัตยกรรมที่ตอบสนองความต้องการของระบบและผู้ใช้ รวมถึงคนที่ทำงานกับระบบนั้นเองด้วย การมองแค่ด้านเดียว เช่น มอง logical แต่ไม่มอง physical หรือมองแค่รูปทรงแต่ไม่มองประสบการณ์ของนักพัฒนา จะจำกัดประสิทธิภาพของสถาปนิก ถ้าคุณยอมรับว่าสถาปัตยกรรมคือการเข้าใจระบบ การจำกัดขอบเขตสิ่งที่คุณสนใจก็จำกัดความสามารถในการให้เหตุผลและสร้างการเปลี่ยนแปลงของคุณด้วย

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

อีกคำพูดคมๆ ที่มักถูกใช้นิยามสถาปัตยกรรมซอฟต์แวร์มาจากบทความเดียวกันที่ Martin แชร์มุมมองของ Ralph ไว้ว่า: "So you might end up defining architecture as things that people perceive as hard to change. " แนวคิดของ Martin ที่ว่าสถาปัตยกรรมคือสิ่งที่ยากจะเปลี่ยนแปลงนั้นสมเหตุสมผลในระดับหนึ่ง และพาเรากลับไปสู่แนวคิดสถาปัตยกรรมในโลกของสิ่งปลูกสร้าง ยิ่งสิ่งใดยากที่จะเปลี่ยนแปลง ยิ่งต้องคิดล่วงหน้าให้มากขึ้นเพื่อให้แน่ใจว่าเรากำลังเดินไปในทิศทางที่ถูกต้อง แต่การเอานิยามง่ายๆ ของแนวคิดที่ซับซ้อนมาใช้เป็นนิยามการทำงานก็มีปัญหา ถ้าคำพูดนี้เป็นวิธีเดียวที่คุณคิดเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ คุณจะพลาดอะไรไปมาก ใช่ สถาปัตยกรรมซอฟต์แวร์ส่วนใหญ่คือการคิดถึงสิ่งที่จะเปลี่ยนแปลงยาก แต่มันก็เป็นเรื่องของการสร้างพื้นที่ให้เกิดการเปลี่ยนแปลงในการออกแบบด้วยเช่นกัน